JP2015198452A - ビデオストリーミングの方法、対応するデバイスおよびシステム - Google Patents

Abstract

【課題】ビデオストリーミングの方法、対応するデバイスおよびシステムを提供する。【解決手段】ビデオは、チャンクでプレーヤに提供される。一部のチャンクは、それらのチャンクが特定のユーザをターゲットにするため、計算される必要がある。ターゲット設定済みチャンクのコンピューティングは、関連するキューからジョブをポップするクラウドコンピューティングインスタンスによって行われる。ターゲット設定済みチャンクは、プレーヤがトリックモードを使用するため、最初の見込みよりも早くまたは遅く要求される場合がある。ターゲット設定済みチャンクを正しい時間にプレーヤに送信するために、再生時間トラッカは定期的に、オーバーロードされたチャンクリクエストをマニフェストファイルに挿入する。オーバーロードされたリクエストは、未来に必要とされるターゲット設定済みチャンクの参照ならびにこれらのチャンクのプレイアウト見込み時間を含む。【選択図】図６

Description

本開示は、クラウドコンピューティングの分野に関し、具体的には、クラウドコンピューティングを使用するターゲットビデオ環境においてビデオチャンクを提供するための最適な計算コストを維持する分野に関する。

広告をコンテンツに挿入して消費者にブロードキャストすることが、コンテンツサービスプロバイダの財源として長い間行われてきた。双方向データ通信ネットワークを介してメディアファイルを消費者デバイスにストリーミングすることが当たり前となり、オンデマンドのビデオストリーミングがますます成功を収めている。ＴＶｏＤ（ＴＶオンデマンド）またはＴＶ再生、Ｔｉｍｅ ＳｈｉｆｔおよびＶｏＤ（ビデオオンデマンド）の技術によって、コンテンツを個々のユーザに送信することが可能である。この新しいコンテンツ消費モデルは、いわゆるターゲット広告から収益を挙げる機会を作る。ターゲット広告は、消費者のグループまたは個々の消費者をターゲットにする広告である。ターゲティングは、人口統計学的情報または消費者プロファイルに基づく。広告は、通常、リクエストされたビデオの開始時に挿入される追加的なビデオシーケンスであり、追加的な広告ビデオは、視聴の間またはリクエストされたビデオの終了時に挿入される。しかしながら、消費者は、挿入されたコマーシャル休憩(advertisement breaks)をスキップする傾向があり、これは、コンテンツプロバイダの減収を意味する。ソリューションは、挿入された広告がプレイアウトされる時にビデオトリックモードのブロッキングを行い、従って、挿入された広告をスキップ不可能にすることを含む。これは、サービスプロバイダにとっても、消費者にとっても満足のいくソリューションではない。従って、コンテンツ自体を直接変更できるようにして、コマーシャル休憩を挿入する代わりに、コンテンツビデオフレームが広告を含むように変更され、それによって、スキップ不可能なコマーシャル休憩を挿入する必要性を取り除く、代替のソリューションが開発されている。特許文献１において、主発明者であるＭｃＡｌｉｓｔｅｒは、ビデオをユーザにストリーミングする間にビデオフレームの広告映写領域がターゲット広告に置き換わることを説明している。広告は、もはやコマーシャル休憩に集中するのではなく、ビデオフレームの一部であり、従って、もはや消費者によって回避されることができない。オーバーレイング(overlaying)として周知であるこの技術は、ビデオフレーム内に広告映写領域を含むことが必要である。広告映写領域は、ビデオコンテンツを消費者にストリーミングする時に認識されて、ターゲット広告が広告映写領域に置き換わる。しかしながら、ＶｏＤサーバがコンテンツの人気およびタイムスロットに応じて大きく変動する需要に対応することは周知である。置換動作は、ストリーミング中に実施され、高い計算能力を必要とする。この動作状況において、ＶｏＤストリーミング中にターゲット広告が広告映写領域に置き換わるソリューションのスケーラビリティは、問題をはらんだままである。

従って、ビデオをユーザにストリーミングする間に、プレイアウト見込み時間に最小コストで、ターゲット広告がビデオコンテンツのビデオフレームのピクセル領域にオーバーレイされることを確保するスケーラブルな技術的解決法を提供する必要がある。

国際航海番号第ＷＯ２００２／３７８２８Ａ２号公開パンフレット

開示される方法、デバイスおよびシステムは、背景技術の節において論じた少なくとも一部の欠点を解決する。

この目的のため、本開示は、第１の実施形態においてビデオストリーミングの方法を含む。この方法は、ビデオプレーヤデバイスから、ビデオを上記ビデオプレーヤデバイスにストリーミングするリクエストを受信するステップを含む。ビデオをストリーミングする上記リクエストに応答して、上記デバイスは、上記ビデオを再生するビデオチャンクのリソースロケータを含むビデオチャンクリストを上記ビデオプレーヤデバイスに送信する。上記ビデオチャンクリストは、第１のリソースロケータタイプのリソースロケータと第２のリソースロケータタイプのリソースロケータを含む。第１のリソースロケータタイプは、単一のビデオチャンクを参照し、第２のリソースロケータタイプは、第１のビデオチャンクを参照する第１のリソースロケータと、第２のビデオチャンクを参照する第２のリソースロケータと、第２のビデオチャンクのプレイアウト見込み遅延とを含む。この方法は、上記ビデオプレーヤデバイスから、上記ビデオチャンクリストからのビデオチャンクをストリーミングするリクエストを受信するステップをさらに含む。ビデオチャンクをストリーミングする上記リクエストに含まれるリソースロケータが第１のリソースロケータタイプであれば、上記デバイスは、単一のビデオチャンクを上記ビデオプレーヤデバイスに送信する。しかしながら、ビデオチャンクをストリーミングする上記リクエストに含まれる上記リソースロケータが第２のリソースロケータタイプであれば、このデバイスは、上記ビデオプレーヤデバイスに第１のビデオチャンクを送信し、そして第２のビデオチャンクが利用できなければ、上記デバイスは、第２のビデオチャンクを計算するリクエストを送信し、第２のビデオチャンクを計算する上記リクエストは、プレイアウト見込み遅延を含む。

ビデオストリーミングの方法の第２の実施形態によれば、第２のビデオチャンクを計算するリクエストは、ビデオチャンクのコンピューティングをスケジュールするスケジューラに送信される。スケジューラは、ビデオチャンクを計算するための複数のジョブキューを含み、複数のジョブキューのうちの各ジョブキューは、特定のカテゴリのコンピューティングインスタンスによって処理され、そして各コンピューティングインスタンスは、計算されたビデオチャンクをキャッシュメモリに格納する。スケジューラは、ビデオチャンクを計算するジョブを、関連するプレイアウト見込み遅延に従って選択された特定のカテゴリのキューに帰属させる。

ビデオストリーミングの方法の第３の実施形態によれば、計算するリクエストを受信すると、スケジューラは、第２のビデオチャンクの参照に対応するジョブが計算結果をプレイアウト見込み遅延の範囲内で返す見込みがあるかどうかを検証する。その範囲内で返す見込みがなければ、スケジューラは、第２のビデオチャンクの参照に対応するジョブのコピージョブを至急カテゴリ(category urgent)のキューに挿入する。

ビデオストリーミングの方法の第４の実施形態によれば、計算するリクエストを受信すると、スケジューラは、第２のビデオチャンクの参照に対応するジョブが計算結果をプレイアウト見込み遅延の範囲内で返す見込みがあるかどうかを検証する。その範囲内で返す見込みがなければ、スケジューラは、至急カテゴリのキュー内にある第２のビデオチャンクの参照に対応するコピージョブを移動する。

ビデオストリーミングの方法の第５の実施形態によれば、方法は、各キューをキューサイズの関数として機能させるコンピューティングインスタンスを追加または除去することをさらに含む。この第５の実施形態は、第２から第４の実施形態までのいずれとも組み合わされて、特定の有利な実施形態を提供することができる。

ビデオストリーミングの方法の第６の実施形態によれば、ジョブキューのカテゴリは、少なくともベストエフォートキュー(best effort queue)および至急キュー(urgent queue)を含む。この第６の実施形態は、第２から第５の代替の実施形態までのいずれとも組み合わされて、特定の有利な実施形態を提供することができる。

ビデオストリーミングの方法の第７の実施形態によれば、計算は、ビデオプレーヤデバイスのユーザをターゲットにするコンテンツにビデオチャンクの画像フレーム内のピクセルゾーンをオーバーレイすることを含む。この第７の実施形態は、これまでの実施形態のいずれとも組み合わされて、特定の有利な実施形態を提供することができる。

本開示はさらに、デバイスにも関連する。開示されるデバイスは、プロセッサ、トランスミッタおよびレシーバを含む。このレシーバは、ビデオプレーヤデバイスから、ビデオをビデオプレーヤデバイスにストリーミングするリクエストを受信するように構成される。上記トランスミッタは、ビデオをストリーミングする上記リクエストに応答して、ビデオプレーヤデバイスに、リクエストされたビデオのビデオチャンクのリソースロケータを含むビデオチャンクリストを送信するように構成される。上記ビデオチャンクは、第１のリソースロケータタイプのリソースロケータと第２のリソースロケータタイプのリソースロケータを含む。上記第１のリソースロケータタイプは、単一のビデオチャンクを参照する。上記第２のリソースロケータタイプは、第１のビデオチャンクを参照する第１のリソースロケータと、第２のビデオチャンクを参照する第２のリソースロケータと、第２のビデオチャンクのプレイアウト見込み遅延とを含む。上記レシーバは、上記ビデオプレーヤデバイスから、上記ビデオチャンクリストからのビデオチャンクをストリーミングするリクエストを受信するようにさらに構成される。上記プロセッサは、ビデオチャンクをストリーミングするリクエストに含まれるリソースロケータが第１のリソースロケータタイプであるかどうかを判定するように構成され、そして上記トランスミッタは、ビデオチャンクをストリーミングする上記リクエストに含まれるリソースロケータが第１のリソースロケータタイプであれば、ビデオプレーヤデバイスに単一のビデオチャンクを送信するようにさらに構成される。上記プロセッサは、ビデオチャンクをストリーミングするリクエストに含まれるリソースロケータが第２のリソースロケータタイプであるかどうかを判定するようにさらに構成される。上記トランスミッタは、ビデオチャンクをストリーミングする上記リクエストに含まれるリソースロケータが第２のリソースロケータタイプであれば、第１のビデオチャンクをビデオプレーヤデバイスに送信するようにさらに構成され、そして上記プロセッサは、第２のビデオチャンクが利用できないかどうかを判定するようにさらに構成される。上記トランスミッタは、第２のビデオチャンクが利用できなければ、第２のビデオチャンクを計算するリクエストを送信するようにさらに構成され、第２のビデオチャンクを計算するリクエストは、第２のビデオチャンクの参照およびプレイアウト見込み遅延を含む。

本開示はさらに、上記のデバイスを含むシステムも含む。システムは、ビデオチャンクのコンピューティングをコンピューティングインスタンスにスケジュールするように構成されたスケジューラと、計算されたビデオチャンクを格納するように構成されたキャッシュメモリをさらに含む。トランスミッタは、第２のビデオチャンクを計算するリクエストをスケジューラに送信するようにさらに構成される。スケジューラは、ビデオチャンクを計算するための複数のジョブキューを格納するメモリを使用し、複数のジョブキューのうちの各ジョブキューは、特定のカテゴリのコンピューティングインスタンスによって処理され、各コンピューティングインスタンスは、利用可能な計算されたビデオチャンクをキャッシュメモリに格納し、そしてスケジューラは、ビデオチャンクを計算するジョブを、関連するプレイアウト見込み遅延に従って選択された特定のカテゴリのキューに帰属させる。

システムの変形実施形態によれば、スケジューラは、計算するリクエストを受信すると、第２のビデオチャンクの参照に対応するジョブが計算結果をプレイアウト見込み遅延の範囲内で返す見込みがあるかどうかを検証し、そしてその範囲内で返す見込みがなければ、第２のビデオチャンクの参照に対応するジョブのコピージョブを至急カテゴリ(category urgent)のキューに挿入するようにさらに構成される。

システムの変形実施形態によれば、スケジューラは、計算するリクエストを受信すると、第２のビデオチャンクの参照に対応するジョブが計算結果をプレイアウト見込み遅延の範囲内で返す見込みがあるかどうかを検証し、そしてその範囲内で返す見込みがなければ、至急カテゴリのキュー内にある第２のビデオチャンクの参照に対応するコピージョブを移動するようにさらに構成される。

システムの変形実施形態によれば、スケジューラは、各ジョブキューをジョブキューサイズの関数として機能させるコンピューティングインスタンスを追加または除去するようにさらに構成される。

本開示はまた、通信ネットワークからダウンロード可能および／またはコンピュータによって読み取り可能な媒体に記録されおよび／またはプロセッサによって実施可能なコンピュータプログラム製品も含み、コンピュータプログラム製品は、第１から第７までの実施形態のいずれかによる方法のステップを実行するプログラムコード命令を含む。

本開示はまた、非一時的コンピュータ可読媒体も含み、そのコンピュータ可読媒体は、その媒体上に記録されおよび第１から第７までの実施形態のいずれかによる方法のステップを実行するプログラムコード命令を含む、プロセッサによって実行することができる、コンピュータプログラム製品を含む。

本開示の実施形態の他の特性および利点は、以下の説明および添付図面を読むと明らかになる。
ターゲットコンテンツのオーバーレイングのプロセスを示す図である。 ターゲット設定可能ビデオチャンクを判定するためのビデオの前処理を示す図である。 マニフェストファイルの生成および使用を示す図である。 Ａｍａｚｏｎ ＡＷＳを使用して、ビデオチャンクの画像フレームのピクセル領域にオーバーレイとしてターゲット広告を含むビデオストリームを提供するためのクラウドコンピューティング手段の使用を示す図である。 ターゲット設定済みビデオチャンクコンピューティングの例示的なクラウドコンピューティング環境を概略的に示す図である。 本発明の実施形態による再生時間トラッカと他のモジュールとの間の相関関係を示す図である。 本発明による方法の特定の実施形態を示すフローチャートである。 本発明の方法の実施形態を実装する例示的なデバイスを示す図である。

以下の説明では、例示的実施形態を提供する。これらの実施形態は、本開示の範囲、適用性または構成を限定することを意図せず、むしろ当業者に実施形態の実装を可能にする説明を与える。本開示の範囲内にある限り例示的な好適実施形態の機能および配置においてさまざまな変更が行われてもよいことを理解されたい。

以下の説明において、用語「オーバーレイング」は、コンテンツをビデオフレームの元コンテンツにオーバーレイするアクションを表す。この結果、元々ビデオフレームに含まれていた少なくとも一部のピクセルがオーバーレイ画像のピクセルに置き換えられたビデオフレームとなる。透明度、色の設定およびコントラストなどの、フィーチャを使用して、オーバーレイ画像を元のビデオフレームコンテンツに適用することができる。

以下の説明において、ビデオコンテンツの一連の連続画像フレームは、「ビデオチャンク」と呼ばれる。ターゲット広告によりオーバーレイするためにオーバーレイ可能なピクセルゾーンを含むビデオコンテンツの一連の連続画像フレームは、「ターゲット設定可能ビデオチャンク」と呼ばれる。ターゲットコンテンツがオーバーレイされた一連の連続画像フレームは、「ターゲット設定済みビデオチャンク」と呼ばれる。ビデオコンテンツを消費者デバイスにストリーミングする間に、ビデオコンテンツは、判定されたターゲット設定可能ビデオチャンクによって特定の消費者をターゲットにする広告をオーバーレイすることによって特定のユーザに適用され、このように取得されたターゲット設定済みビデオチャンクは、ビデオコンテンツの一部として消費者にストリーミングされる。

以下の説明において、コンピューティングという用語は、ターゲット設定可能ビデオチャンクからターゲット設定済みビデオチャンクを取得するための処理動作を指定するために使用される。

以下の説明において、プレイアウト遅延という用語は、所与の時からカウントされる、例えば、所与のビデオチャンクからカウントされる遅延を指定するために使用され、その遅延の範囲内でビデオプレーヤによって別のビデオチャンクをプレイアウトする必要性が見込まれる。代替として、プレイアウト見込み「遅延」は、むしろプレイアウト見込み「時間」であり、ビデオプレーヤによって別のビデオチャンクをプレイアウトする必要性が見込まれる場合、例えば、ＮＴＰ(Network Time Protocol)、複数のデバイス間で共有される共通の時間基準、などの、基準クロックの時間、または未来時の実時間(wall clock time) またはクロック基準に対応する。

原則として、クラウドコンピューティングは、潜在的に無制限なオンデマンドコンピューティングリソースを可能にするので、要求されたスケーラビリティを提供することができる。Ａｍａｚｏｎ ＡＷＳによって提供されるような、クラウドコンピューティングプラットフォームでは、コンピューティングインスタンスの価格設定(pricing)は、計算速度と所与の時に計算結果を準備しておく保証とによって決まる。理想的には、ターゲット設定済みビデオチャンクのコンピューティングは、クラウドコンピューティングプラットフォームによって提供されるさまざまなタイプのコンピューティングインスタンスを介して、計算コストを最適化する方法で送られることができる。例えば、オンデマンドビデオの開始に近いターゲット設定可能ビデオチャンクの場合、比較的高いコスト、比較的高速のクラウドコンピューティングインスタンスが要求される一方、開始から２０分におけるターゲット設定可能ビデオチャンクの場合、比較的低いコスト、比較的低速のクラウドコンピューティングインスタンスで十分である。しかしながら、説明されるように、いくつかの考察がこの理想的なシナリオを乱す。

（ｉ）消費者は、彼／彼女がトリックモードを使用できるので、オンデマンドビデオを直線的なやり方で見るように強制されない。故に、消費者のトリックモードアクションにより、ビデオチャンクは、従って、プレイアウトが予想されるよりも早くまたは遅くされる必要があり得る。

（ii）クラウドコンピューティングインスタンスの価格設定は、入札によって判定されるので、安定していない。

（iii）比較的低価格のクラウドコンピューティングインスタンス（例えば、Ａｍａｚｏｎ‘スポット’）は、所与の遅延の範囲内で結果を与えるように保証されていない。

（iv）標準のクラウドコンピューティングインスタンスでさえも、ジョブが完了する前に機能しなくなる可能性がある。

図１は、ストリーミングされるビデオコンテンツにオーバーレイするターゲットコンテンツの処理を示している。画像フレーム１０は、変更のないビデオの元画像フレームを表す。画像フレーム１１は、ターゲットコンテンツ１１１が、ここでは橋の欄干にオーバーレイされた、変更されたビデオ画像フレームを表す。

図２は、ターゲット設定可能ビデオチャンクを判定するためのビデオの前処理を示している。アイテム２０は、ビデオシーケンスを表す。アイテム２１、２２および２３は、ビデオの前処理中に判定される、ターゲットコンテンツをオーバーレイすることができるピクセル領域を含む、ビデオ画像フレームを表す。これらのピクセル領域を、例えば、変更に関して比較的安定している連続フレーム内のピクセルエリアの検出によって認識するための異なる技術を用いることができる。

図３は、本発明の１または複数の実施形態によるマニフェストファイルの生成および使用を示している。この例に使用されるシナリオによれば、二人の消費者３３と３４が存在する。これらの消費者がビデオをリクエストすると、各々は、マニフェストファイルを受信する。消費者３３は、マニフェストファイル３２を受信する。消費者３４は、マニフェストファイル３１を受信する。マニフェストファイルは、マニフェスト生成機能３０によって生成される。マニフェストファイルは、リクエストされたビデオのビデオチャンクをポイントするＵＲＬを含む。マニフェストファイルは、従って、所与のビデオコンテンツのビデオチャンク部分のリストである。消費者３３の場合、マニフェストファイルは、すべての消費者にとって同じである、ジェネリックビデオチャンク３５をポイントするＵＲＬ１と、ビデオチャンクの画像に出ている橋の欄干に対応するピクセル領域にオーバーレイされた広告を含むターゲット設定済みビデオチャンク３６ａをポイントするように、具体的に消費者３３をターゲットにするＵＲＬ３とを含む。消費者３４は、ＵＲＬ１とＵＲＬ２を含むマニフェストファイルを受信する。ＵＲＬ１は、消費者３３のものと同じである。ＵＲＬ２は、消費者３３および３４にとって同じである、ジェネリックビデオチャンク３６をポイントする。消費者の消費者デバイス（図示せず）のそれぞれにあるビデオプレーヤは、ビデオチャンクを受信して再生するために、マニフェストファイルを読み取って、被参照ＵＲＬをフェッチする。

図４は、本発明の１または複数の実施形態が実装され得る、Ａｍａｚｏｎ ＡＷＳを使用して、ビデオチャンクの画像フレームのピクセル領域におけるオーバーレイとしてターゲット広告を含むビデオストリームを提供するためのクラウドコンピューティング手段の使用を示している。

●「ＥＣ２」（エラスティック・コンピュート・クラウド；ＥＣ２マイクロ４０１，ＥＣ２スポット４０２，ＥＣ２ラージ４０７）などの、コンピューティングインスタンスは、（ターゲティング、オーバーレイング、ユーザプロファイリング、マニフェストファイル生成などの）計算タスクを実行する。ＥＣ２は、大規模な計算能力を提供し、かつ異なる種類のオペレーティングシステムおよび異なる種類の「インスタンス」コンフィギュレーションのための仮想コンピューティング環境を提供する、ウェブサービスである。典型的なインスタンスコンフィギュレーションは、「ＥＣ２標準」または「ＥＣ２マイクロ」である。「ＥＣ２マイクロ」インスタンスは、追加的な計算サイクルを定期的に要求するより低いスループットアプリケーションおよびウェブサイトによく適している。ＡＷＳでリソースを得る異なる方法がある。最初の方法は、「オンデマンド」と呼ばれ、リソースが所与の価格で利用できるようにすることを保証する。第２のモードは、「スポット」と呼ばれ、より安い価格でリソースを得ることを可能にするが、可用性の保証はない。「ＥＣ２スポット」インスタンスは、入札機構によってＥＣ２計算能力の価格を取得することが可能である。これらのインスタンスは、時間に柔軟性のある、中断に耐性のある（interruption-tolerant）タスクの計算コストを大幅に下げることができる。価格は、同じＥＣ２インスタンスタイプのオンデマンド価格よりも大幅に低いことが多い。

●「Ｓ３」（シンプルストレージサービス；４０４，４０５，４０６）などのストレージインスタンスは、ジェネリックおよびターゲット設定可能ビデオチャンクなどのデータを格納する。「Ｓ３」は、任意の量のデータをいつでも格納して読み出すために使用することができる単純なウェブサービスインタフェースを提供する。格納スペース価格は、望まれる信頼性、例えば、高い信頼性を持ち、かつ重要でない、再現可能なデータを格納する冗長格納が削減された標準ストレージによって決まる。

●「クラウドフロント(CloudFront)」（４０３）は、データ配信を提案する。クラウドフロントは、コンテンツ配信のウェブサービスであり、そして他のＡＷＳサービスと統合して、低レイテンシーおよび高データ転送速度でコンテンツをエンドユーザに配布し、そしてコンテンツのストリーミングに使用することができる。

図において、要素４００は、セットトップボックス、ＰＣ、タブレット、またはモバイル電話などの、ユーザデバイスを示す。リライアブルＳ３ ４０４は、ジェネリックおよびターゲット設定可能ビデオチャンクの格納に使用される。リデュースド・リライアブルＳ３（４０５）は、容易に再計算することができるターゲット設定済みビデオチャンクの格納に使用される。リデュースド・リライアブルＳ３（４０５）は、ターゲット設定済みビデオチャンクをしばらくの間メモリに保存するために、キャッシュとして使用される。リライアブルＳ３ ４０６は、ターゲット設定可能ビデオチャンク、広告またはオーバーレイコンテンツの格納に使用される。ＥＣ２スポットインスタンス４０２は、ターゲット設定済みビデオチャンクを事前計算するために使用される。ＥＣ２スポットインスタンスによるこの計算は、「バッチ」コンピューティングと呼ぶことができ、例えば、マニフェスト生成の直後にトリガされる。オンデマンドＥＣ２ラージインスタンス（４０７）は、「オンザフライ」または「リアルタイム」のオーバーレイングを実現するために使用される。ターゲット設定済みビデオチャンクのコンピューティングは、以下のように行われる：ターゲット設定可能ビデオチャンクがＳ３リライアブル（４０６）から読み出され、ターゲット設定可能ビデオチャンクがデコードされ、オーバーレイコンテンツが選択され（例えば、ユーザの選好に応じて選択される、広告）、ターゲット設定可能ビデオチャンクの画像フレームのピクセル領域にオーバーレイされ、そして画像フレームが再エンコードされ、このようにしてターゲット設定済みビデオチャンクを取得する。前述したターゲット設定済みビデオチャンクの「オンザフライ」または「バッチ」コンピューティングに応じて、ターゲット設定可能ビデオチャンクのデコーディング、オーバーレイコンテンツの選択、オーバーレイングおよび再エンコーディングは、それぞれＥＣ２スポットインスタンス（４０２）またはＥＣ２ラージインスタンス（４０７）のいずれかにおいて行われる。もちろん、この説明された変形形態は、実現可能ないくつかのストラテジーのうちの１つにすぎない。他のストラテジーは、異なるＥＣ２インスタンス（例えば、マイクロ、ミディアムまたはラージ）を、遅延、タスクサイズおよびコンピューティングインスタンスコストなどの、異なるパラメータに依存する「オンザフライ」または「バッチ」コンピューティングのいずれかに使用することを含み、これらのインスタンスの使用が最適化されて品質の良いサービスによるコスト効率の高いソリューションを提供するようにできる。ターゲット設定済みビデオチャンクはその後、「バッチ」コンピューティングの場合にキャッシュとして使用されるリデュースド・リライアブルＳ３（４０５）に格納されるか、または「オンザフライ」コンピューティングの場合にＥＣ２ラージ４０７から直接提供されるか、およびオプションとして、リデュースド・リライアブルＳ３ ４０５に格納されるいずれかである。ターゲット設定済みビデオチャンクのバッチコンピューティングは、それを行うための時間が空いていれば、計算コストの理由で好ましい。従って、ターゲット設定済みビデオチャンクのバッチコンピューティングを開始する適切な時は、マニフェストが生成される時である。しかしながら、ユーザがまだ計算されていないターゲット設定可能ビデオチャンクを早送りするのであれば、よりコストのかかる「オンザフライ」コンピューティングが要求される。

従って、ビデオ再生のタイムライン上のターゲット設定可能ビデオチャンクのロケーションに応じて、クラウドコンピューティングインスタンスは、コストを最適化するストラテジーにより選択される。ストラテジーは、マニフェストファイルが生成された直後に決定される。しかしながら、コンピューティングストラテジーは、ユーザが早送りなどの、トリックモードを使用すれば、再考されなければならない。ターゲット設定済みビデオチャンクのコンピューティングがスポットインスタンスで開始されるのであれば、ターゲット設定済みビデオチャンクが、ユーザがビデオを早送りしても間に合う時間に利用できるという保証がなくなる。その結果、ビデオチャンクのプレイアウトが予期しないイベントの場合にビデオチャンクの可用性を確保する前に、しばらくコンピューティングストラテジーを再考する必要がある。実現可能なソリューションは、ＶｏＤサーバにおいてユーザの再生時間(play-time)をトラックすることになる。しかし、これは、すべてのＶｏＤユーザの再生時間をモニタリングすることを要求することになる。このようなソリューションは、スケーラビリティを損なうことになる。そして、一般的に、クラウドベースのソリューションは、クラウドサーバ間の負荷バランシングを軽減するためにステートレス(stateless)設計が要求される。従って、チャンクをプレイアウト見込み時間に提供できるようにするために、ビデオチャンクのコンピューティングストラテジーを十分に前もって再考することを可能にするステートレスソリューションを提供することが望ましい。本発明の実施形態は、ビデオチャンクの配信の再生時間をトラックする方法およびデバイスを提供する。

ユーザが所与のビデオをリクエストするとき、ビデオ内のターゲット設定可能ビデオチャンクが、これらのチャンクをユーザプロファイルにより特定のユーザをターゲットにするコンテンツにオーバーレイする決定が行われる。マニフェストファイルが生成されて、ユーザに送信される。キャッシュエリアにおいてもはや利用できないビデオのすべてのターゲット設定済みビデオチャンクに対し、ターゲット設定済みビデオチャンクを計算するジョブが生成されて、ジョブシーケンスにポストされる。ジョブは、「ターゲット設定済みチャンク計算リクエスト」であると見なすことができる。各ジョブは、ターゲット設定済みビデオチャンクを計算するために使用できる遅延または時間制限を指定する、プレイアウト見込み時間パラメータまたはプレイアウト見込み遅延パラメータを備える。プレイアウト見込み時間は、ターゲット設定済みビデオチャンクが、実際の再生位置および再生速度が与えられたビデオプレーヤによって必要とされるはずの見込み時間である。プレイアウト見込み時間は、ターゲット設定済みビデオチャンクをストレージ装置からビデオプレーヤに送信するための格納および送信遅延を考慮に入れるために追加的な限界遅延を含むことができる。異なるタイプのクラウドインスタンスは、計算速度および単位時間当たりのコストなどの、パラメータによって特徴付けられる。計算速度は、例えば、１は、計算継続期間がビデオチャンクのプレイアウト継続期間と等しいことを意味し、２は、計算継続期間がプレイアウト継続期間の２倍であることを意味するなど、リアルタイムのビデオのプレイアウト速度の比率として表すことができる。もちろん、これは、インスタンスの特性、例えば、ＡＷＳ ＥＣ２、ＥＣＵ(EC2 Compute Units)の数によって異なる。異なるジョブシーケンスは、計算速度および信頼性に関してクラウドコンピューティングインスタンスの異なる特性により定義される。

図５は、ターゲット設定済みビデオチャンクコンピューティングの例示的なクラウドコンピューティング環境を概略的に示している。図示されているのは、スケジューラ５０、ジョブシーケンス５１、インスタンスプール５２、スケーラ(scaler)５３、およびキャッシュ５４である。キュー内のジョブは、ターゲット設定済みビデオチャンクのビデオチャンク識別子およびビデオチャンクのプレイアウト見込み時間に関係する関連情報を含む。スケジューラは、ターゲット設定済みビデオチャンクを計算するリクエストを受信して、ジョブを生成する。スケジューラは、プレイアウト見込み時間によりどのキューにジョブが配置されるかを決定する。インスタンスプールは、キューからのジョブを、例えば、ＦＩＦＯ順序（先入れ、先出し）でフィードされる。キュー内のジョブのターゲット設定済みビデオチャンクが既にキャッシュ内に存在していれば（即ち、ターゲット設定済みビデオチャンクは、「アベイラブル」であると言える）、ジョブは、キューから除去されて、次のジョブがフェッチされる。まだキャッシュ内に存在してなければ、ジョブが開始される。ビデオチャンクが計算されると、それらのチャンクは、キャッシュに格納される（即ち、ターゲット設定済みビデオチャンクである、計算結果がメモリエリアに格納される。キャッシュは、メモリエリアの例であり、メモリエリアの他の例は、データベース、揮発性または不揮発性メモリ、外部または内部ストレージ装置である）。計算されたビデオチャンクは、消費者デバイス（図示せず）上でキャッシュからビデオプレーヤに配信される。図５の例示的実施形態において、４つのタイプのキュー：「ベストエフォート」キューＱ１と、至急のジョブ用の「至急」キューＱ２と、「通常の」ジョブ用の「通常」キューと、「オプションの」ジョブ用の「オプショナル」キューＱ４とが示されている。各特定のキュー内のジョブは、特定のインスタンスプール：「ベストエフォート」キューＱ１用の「スポットＸラージ」インスタンスプールと、「至急」キューＱ２用の「Ｘラージ」インスタンスプールと、「通常」キューＱ３用の「Ｘラージ」インスタンスプールと、「オプショナル」キューＱ４用の「スポットマイクロ」インスタンスプールとに帰属される。スケーラ５３は、キューＱ１およびＱ３のジョブフローにより「スポットＸラージ」および「Ｘラージ」インスタンスプールからインスタンスを追加または除去する。特定のキューを提供する所与のプールの特定のインスタンスを開始／停止するためのいくつかのスケーリングストラテジーがあり得る。所与のキューに対する固有のスケーリングストラテジーがある。スケーリングストラテジーは、いつ新しいインスタンスをインスタンスプールから開始すべきかを、例えば、キュー内に存在するジョブの数を判定することによって、またはインスタンスプール内の現在のインスタンスのステータスを判定することによって決定する。スケーリングストラテジーはさらに、いつ所与のインスタンスが停止されて、そしていつインスタンスプールから除去されるかも決定する。所与のキューの場合、２つの極端な場合がある：

（ｉ）ストラテジーがコストを最適化することであれば、ストラテジーは、インスタンスをアイドルステートにするのを回避するように試みる（即ち、ターゲット設定済みビデオチャンクのコンピューティングに使用されないようにする）。インスタンスが１時間毎にチャージされると仮定すると、ストラテジーは、新しいインスタンスを開始する前にキューが比較的一杯になるまで待機することになる。その極端な場合において、ビデオチャンクを計算するレイテンシーは、比較的高くなる。

（ii）他方の極端な場合において、ストラテジーはレイテンシーを最小化することであり、ストラテジーは、できるだけ最小のキューを有するように試み、一部のインスタンスがある時点においてチャンクを計算しない場合があるというリスクを負う（キューが空である場合。即ち、これらのインスタンスは、「アイドルステート」と言える）。

インスタンスの開始および停止は、キュー内のジョブの数、現在実行しているインスタンスの数およびそれらのタイプを観察して行われる。キューは、従って、キューを提供するインスタンスプールおよびキューのスケーリングストラテジーの特性によって定義される。スポットインスタンスは、インスタンスが許可されるという保証がないという点で他のインスタンスとは異なる。しかしながら、許可されるのであれば、その価格は、他のタイプのインスタンスと比較して比較的低くなる。スポットインスタンスは、いつでも、許可された後でさえもシャットダウンされ、１時間以内にシャットダウンされるのであれば、インスタンスは、チャージされない。スケジューラ５０は、ターゲット設定済みビデオチャンクのリクエスト（即ち、「ジョブ」）を受信し、そして各リクエストに対し、スケジューラは、ビデオチャンクの識別子およびプレイアウト前の時間を受信する。スケジューラは、プレイアウト見込み時間によりジョブを正しいキューに帰属させる。プレイアウト見込み時間が閾値を上回れば、ジョブは、ベストエフォートキューＱ１にポストされる。インスタンスプール５２からのインスタンスは、それらのインスタンスが帰属するキューからジョブをフェッチして、それらのジョブを実行する。しかしながら、スポットインスタンスがいつでも強制終了され得るので、可能であればインスタンスはジョブの結果をコミットする時間の前に、未処理のジョブを識別して必要に応じてそれらのジョブを再生成する機構が必要である。ジョブのプレイアウト見込み時間が閾値を下回れば、スケジューラは、プレイアウトの前の時間に応じて再度、通常キューＱ３または至急キューに帰属させる。最も単純な形式の変形実施形態によれば、１つを「低速」ジョブに、１つを「高速」ジョブに向けた、２つのみのキューがある。より一般的な事例の場合、２以上の任意の数のキューがサポートされる。変形実施形態によれば、ジョブが、例えば、プレイアウト見込み時間で順序付けされる、優先キューが定義される。スケーラの役割は、プール内のインスタンスを開始および停止することによってキューの長さを閾値以下に保つことである。キューが大きく拡大中の場合、スケーラは、インスタンスを追加する。キューが小さく縮小中の場合、インスタンスは、停止される。スケーラは、至急キューＱ２のジョブを処理するのに十分な使用されていない(free)高速インスタンスがあることを確保する。プレイアウト期限の前に処理されることができない任意のビデオチャンクは、単純にドロップすることができ、結果としてその場合、どのターゲット設定済みビデオチャンクも提供されない。

図６は、本発明の実施形態による再生時間トラッカと他のモジュールとの間の相関関係を示している。図面は、ＶｏＤカタログウェブサーバ６０、スケジューラ５０、キャッシュ５３、ビデオプレーヤ６１、再生時間トラッカ６２、ビデオサーバ６３、ビデオファイルストレージ６４を示している。

一旦スケジューラ５０がジョブを適切なキューにポストすると、ジョブのポスティングと、関係するターゲット設定済みビデオチャンクが必要になる時との間にある数のイベントが発生し得る：
●キュー内のジョブがスポットインスタンスによって提供される場合、インスタンスがチャンクを計算するプレイアウト見込み時間に割り振られる保証はなく、
●ジョブを現在実施している（即ち、チャンクを計算している）インスタンスは、タスクの完了前に失敗し、どのビデオチャンクも計算されない場合があり、
●ユーザがトリックモードを実施する場合、プレイアウト見込み時間が変化することがあり、その結果、もはやジョブキューの帰属が適切でなくなる。

その結果、スケジューラによって行われる異なるキューにおけるジョブの配置の決定は、リクエストされたターゲット設定済みビデオチャンクが正しい時間に利用可能であり、かつ可能な限り最低のコストで計算される可能性を最大限にするために、定期的に再考される。ステートレスソリューションを用いてこの目的を達成するために、パラメータは、再生時間トラッキングを可能にするビデオチャンクのＵＲＬに挿入される。例えば、ビデオプレーヤに送信されるマニフェストファイルにおいて、１０または２０ビデオチャンク毎にビデオチャンクのＵＲＬは、間もなくリクエストされることが見込まれるビデオチャンクの識別子などの、追加的な情報により、およびプレイアウト時間または遅延時間により「オーバーロード」される。例示的なマニフェストファイルは、このように見える：
＃ｍａｎｉｆｅｓｔ ｆｉｌｅ ｆｏｒ ｖｉｄｅｏ ゛ｍ″
ｈｔｔｐ：／／ｓｅｒｖｅｒ／ｍ／ｃｈｕｎｋ０．ｔｓ
ｈｔｔｐ：／／ｓｅｒｖｅｒ／ｍ／ｃｈｕｎｋ１．ｔｓ
ｈｔｔｐ：／／ｓｅｒｖｅｒ／ｍ／ｃｈｕｎｋ２．ｔｓ
ｈｔｔｐ：／／ｐｔｔｒａｃｋｅｒ／？ｃｈｕｎｋ＝ｍ／ｃｈｕｎｋ６．ｔｓ＆ｄｕｅｉｎ＝２０＆ｄｅｓｔ＝ｈｔｔｐ：／／ｓｅｒｖｅｒ／ｍ／ｃｈｕｎｋ３．ｔｓ
ｈｔｔｐ：／／ｓｅｒｖｅｒ／ｍ／ｃｈｕｎｋ４．ｔｓ
ｈｔｔｐ：／／ｓｅｒｖｅｒ／ｍ／ｃｈｕｎｋ５．ｔｓ
ｈｔｔｐ：／／ｓｅｒｖｅｒ／ｍ／ｃｈｕｎｋ６．ｔｓ
…

以下のアクションは、図中の機能的コンポーネント間の矢印に適用する
１ａ：消費者は、ＶｏＤカタログのコンテンツを探索する
１ｂ：ビデオプレーヤ６１は、選択されたコンテンツのＵＲＬを取得する
１ｃ：消費者は、再生を押す
２ａ：ビデオプレーヤ６１は、ビデオサーバ６３からのコンテンツをリクエストする
２ｃ：ビデオサーバ６３は、スケジューラ５０に、リクエストされたコンテンツのターゲット設定済みビデオチャンクを提供するようにリクエストする
３ａ：ビデオプレーヤ６１は、マニフェストファイルからのＵＲＬをリクエストする
３ｂ：再生時間トラッカ６２は、キャッシュ５３内のビデオチャンク６の可用性を検証する
３ｃ：再生時間トラッカ６２は、ビデオチャンク６がキャッシュ５３内にないと、スケジューラ５０に、ビデオチャンク６の至急ジョブを起動するようにリクエストする
３ｄ：再生時間トラッカ６２は、ビデオチャンク３のリクエストをビデオサーバ６３にフォワードする
３ｅ：ビデオサーバ６３は、ビデオチャンクをキャッシュ５３からフェッチする
３ｆ：ビデオサーバ６３は、ビデオチャンクをビデオファイルストレージ６４からフェッチする
３ｇ：ビデオサーバ６３は、ビデオチャンク３をビデオプレーヤ６１に提供する

ビデオプレーヤ６１を操作する消費者は、ＶｏＤカタログウェブサーバ６０（アクション１ａ）からビデオコンテンツを選択する。一旦消費者がビデオ（例えば、ビデオ「ｍ」）を選択すると、ビデオプレーヤは、コンテンツのＵＲＬを取得して（アクション１ｂ）、消費者は、取得されたＵＲＬを使用する再生コマンドを発行する（アクション１ｃ）ことによってビデオの再生を開始する。再生コマンドは、ビデオサーバ６３に送信される（アクション２ａ）。それに応答して、ビデオサーバは、マニフェストファイルまたはビデオチャンクリスト（例えば、上記のビデオチャンクリスト）をビデオプレーヤに送信する（アクション２ｂ）。ビデオプレーヤ６１は、ビデオが再生される時のマニフェストファイルのエントリに対応する、ｈｔｔｐ取得リクエスト(http get requests)を送信する（アクション３ａ）。オーバーロードされていないＵＲＬのリクエスト（例えば、ビデオチャンク０、１、２、４、５、６の）は、ビデオサーバにフォワードされる（アクション３ｄ）。このように、オーバーロードされたビデオチャンクのリクエストは最初に、（例えば、ビデオチャンク３について）再生時間トラッカに送られ（アクション３ａ）、再生時間トラッカは、再生時間情報を抽出し、そしてリクエストはその後、ビデオサーバにフォワードされる（アクション３ｄ）。リクエストされたすべてのビデオチャンクは、ビデオサーバによって、キャッシュ内にあれば、キャッシュから提供され（アクション３ｅ）、またはキャッシュ内になければ、ビデオファイルストレージから提供され（アクション３ｆ）、そしてビデオチャンクをビデオプレーヤに送信する（アクション３ｇ）。再生時間トラッカによって抽出された（例えば、ビデオチャンク３に関する）再生時間情報は、時間値およびビデオチャンク識別子（この場合はビデオチャンク６を識別する）で構成される。時間値は、プレーヤが、組み込まれたビデオチャンク識別子によって識別されたビデオチャンクをリクエストする前の残り時間を示す。再生時間トラッカは、ターゲット設定済みビデオチャンクがキャッシュ５３内に存在するかどうかを確認する（アクション３ｂ）。ビデオチャンクがキャッシュ内にあれば、アクションは行われない。ビデオチャンクがキャッシュ内になければ、再生時間トラッカは、至急ターゲット設定済みビデオチャンクを計算するリクエストをスケジューラに転送する（アクション３ｃ）。スケジューラに送信されたリクエストは、ビデオチャンク識別子（例えば、ビデオチャンクのＵＲＬ）および上述した時間値を含む。再生時間トラッカからのリクエストを受信すると、スケジューラは、プレイアウト見込み時間（例えば、ビデオチャンク６では２０秒）に基づいて、どうすべきかを決定する：至急リクエストされたビデオチャンクを計算するジョブが信頼性のあるインスタンスによって処理されて、ジョブがプレイアウト見込み時間内に終わる見込みであれば、またはビデオチャンクを計算するジョブが至急キューＱ２内またはオプショナルキューＱ４内にあれば、アクションは必要ない。ビデオチャンクを計算するジョブがベストエフォートキューＱ１内または通常キューＱ３内にあれば、ジョブを至急キューＱ４に移動することが必要な可能性がある。このように、プレイアウト見込み時間に応じて、スケジューラは、ジョブにおけるキューの帰属を変更できる。好適実施形態によれば、スケジューラは、ジョブのキューの帰属を変更しないが、スケジューラが至急キューにポストするコピージョブを作成し、そしてキューからのジョブの実行をインスタンス上で開始する前に、対応するインスタンスは、関係するターゲット設定済みビデオチャンクが既にキャッシュ内にあるかどうかを検証する。既にキャッシュ内にあれば、ジョブを実行する必要がなく、ジョブは、キューから除去されて、インスタンスは、キューから次のジョブをフェッチする。この好適な実施形態は、ジョブが、キューの管理を簡易にするインスタンスによって処理されるためにフェッチされる時以外の時においてジョブをキューから除去することを要求しないという利点を有する。変形実施形態によれば、スケジューラは、キュー内のジョブがジョブに関連するプレイアウト見込み時間内に終わる見込みかどうかを定期的に検証し、そして例えば、必要に応じて、コピージョブを至急キューにポストすることによって、ジョブが時間内に終わる確率を改善するアクションを自動的に行う。スケジューラはまた、インスタンスによって実施されるジョブが遅すぎてプレイアウト見込み時間内に終わる見込みがない展開になるかどうかを検証することもでき、そしてその後、コピージョブを作成して、コピージョブを至急キューにポストする。再生時間トラッカからのリクエストが受信されると、リクエストによって指定されたビデオチャンクに対し、ジョブがプレイアウト見込み時間内に終わる見込みかどうかの追加的な検証が行われる。

代替の実施形態によれば、マニフェストファイルのＵＲＬが署名されて、改善されたセキュリティを提供する。

代替の実施形態によれば、２つのキューが使用され、第１のキューは、スポットインスタンスのプールによって提供され、第２のキューは、非常時にビデオチャンクを計算するオンデマンドインスタンスによって提供される。第１のキューは、プレイアウトの前に計算結果が所定の時間期間（例えば、２０秒）になるように構成される。第２のキューは、計算結果が所定の時間期間以下（例えば、２０秒、１０秒、５秒）になるように構成される。

代替の実施形態によれば、ＵＲＬは、ビデオチャンクの典型的な継続期間が１０秒であれば、定期的に、例えば、６ビデオチャンク毎にマニフェストファイルにオーバーロードされる。ＵＲＬをオーバーロードする頻度は、ある種の妥協である：頻度が高すぎれば、再生時間トラッカは、（例えば、読み込みをサポートするためにいくつかのＥＣ２インスタンスにおいて実行する）かなりのＣＰＵ時間を要求する。頻度が低すぎると、トリックモードアクションを見逃すリスクが生じ、結果として見逃されたターゲット設定済みビデオチャンクの頻度が高くなる。結局のところ、再生時間トラッカのＣＰＵ負荷は、計算コストを意味する。いくつかの変形形態が実行可能である。

（ｉ）計算コストと、マニフェストファイルのＵＲＬをｎ個のＵＲＬ毎にオーバーロードする、応答性との間の妥協である、固定されたＵＲＬオーバーローディング頻度が使用される。値ｎは、平均のビデオチャンク継続期間によって異なる。

（ii）ＵＲＬオーバーローディングは、ターゲット設定済みビデオチャンクが、所定のプレイアウト時間またはプレイアウト遅延範囲内で、例えば、１００秒または２００秒範囲内で必要とされる見込みの場合のみに行われる。

（iii）（ii）の通りであるが、マニフェストファイル内のいくつかのＵＲＬに対して行われる。

（iv）ＵＲＬオーバーローディングは、オーバーロードされた同じＵＲＬのいくつかのターゲット設定済みビデオチャンクに対して行われ、そしてオーバーロードされたＵＲＬによってターゲット設定済みビデオチャンク毎の時間値を指定する。

上述した変形形態を組み合わせて、特定の有利な変形実施形態を形成することができる。

さらなる実施形態によれば、ＵＲＬオーバーローディングの周期性は、例えば、マニフェストファイルの行先であるビデオプレーヤによって選択される再生速度に応じて適用される。例えば、選択された再生速度が早送り１６ｘであれば、ＵＲＬオーバーローディングの周期性は、再生速度が通常の再生（１ｘ）速度である場合の周期性の１６倍以上の頻度である。それは、ターゲット設定可能ビデオチャンクを、表示時間が短縮されたために通常の再生速度よりも速く表示されるコンテンツに提供するため、リソースの浪費と見なされる場合もあるが、この変形形態は、有利には、ビデオプレーヤが通常の再生速度にスイッチバックされると、ターゲット設定済みビデオチャンクを提供するように準備することを可能にする。この図面において、デバイス間の接続は、論理接続として示されているが、すべてのデバイスが、示されている論理接続が行われ得る、図８のネットワーク８０５などの、１または複数のネットワークに接続することができることを当業者には容易に理解されよう。

図７は、本発明の特定の実施形態によるフローチャートである。ステップ７０において、方法に使用される変数およびパラメータが初期化される。ステップ７１において、ビデオをストリーミングするストリーミングリクエストは、ビデオプレーヤから受信される。ステップ７２において、リクエストされたビデオのビデオチャンクのリソースロケータを含む、ビデオチャンクリストは、ビデオプレーヤに送信される。ステップ７３において、ビデオチャンクリストからのビデオチャンクをストリーミングするリクエストは、ビデオプレーヤから受信される。ステップ７４において、ビデオチャンクをストリーミングする当該リクエストに含まれるリソースロケータが第１のタイプであるかどうかが判定される。リソースロケータが第１のタイプであれば、ステップ７５において、リソースロケータによって参照されるビデオチャンクは、ビデオプレーヤに送信され、処理はステップ７１に続く。リソースロケータが第２のタイプであれば、リソースロケータによって参照される第１のビデオチャンクは、ステップ７６において、ビデオプレーヤに送信され、そしてステップ７７において、リソースロケータによって参照される第２のビデオチャンクが（例えば、キャッシュエリア内のストレージ装置においてなど）利用可能であるかどうかが判定される。第２のビデオチャンクが利用可能であれば、処理はステップ７１に続く。第２のビデオチャンクが利用可能でなければ、ステップ７８において、リソースロケータによって参照される第２のビデオチャンクを計算するリクエストは、ターゲット設定済みビデオチャンクを計算するスケジューラに送信される。リクエストは、第２のビデオチャンクの参照およびプレイアウト見込み時間または遅延時間を含み、処理はステップ７１に続く。

図８は、本開示の方法を実装するのに適した例示的なデバイス８００である。デバイス８００は、例えば、図６の再生時間トラッカ６２を実装する。デバイスは、処理ユニット８０１、トランスミッタインタフェース８０２、レシーバインタフェース８０３を含み、それらは、内部データ・通信バス８０４を用いて相互接続される。レシーバインタフェースおよびトランスミッタインタフェースは、デバイスが、ビデオプレーヤ、スケジューラ、キャッシュメモリ、およびビデオサーバなどの、他のデバイスと通信できるようにさせるネットワーク８０５に接続されている。レシーバ８０３は、ビデオをストリーミングするリクエストをビデオプレーヤから受信する。トランスミッタ８０２は、リクエストに応答して、リクエストされたビデオのビデオチャンクのリソースロケータを含むビデオチャンクリストをビデオプレーヤに送信する。リストは、少なくとも２つのタイプのリソースロケータを含み、第１のタイプは、第１のビデオチャンクを参照するリソースロケータを含み、第２のタイプは、第１のビデオチャンクを参照する単一のリソースロケータに加え、第２のビデオチャンクを参照するリソースロケータおよび第２のビデオチャンクのプレイアウト見込み時間または遅延時間を含む。レシーバは、その後、ビデオチャンクリストからのビデオチャンクをストリーミングするリクエストをビデオプレーヤから受信する。処理ユニット８０１は、ビデオチャンクをストリーミングするリクエストに含まれるリソースロケータが第１のタイプであるかどうかを判定する。処理ユニットが、ビデオチャンクをストリーミングするリクエストに含まれるリソースロケータが第１のタイプであると判定したのであれば、トランスミッタは、単一のリソースロケータによって参照される第１のビデオチャンクをビデオプレーヤに送信する。処理ユニットが、リクエストに含まれるリソースロケータが第２のタイプであると判定したのであれば、トランスミッタは、複数のリソースロケータによって参照される第１のビデオチャンクをビデオプレーヤに送信し、そして処理ユニットは、複数のリソースロケータによって参照される第２のビデオチャンクが利用可能であるかどうかを判定する。処理ユニットが、第２のビデオチャンクが利用できないと判定すれば、トランスミッタは、第２のビデオチャンクを計算するリクエストを送信する。第２のビデオチャンクを計算するリクエストは、第２のビデオチャンクの参照およびプレイアウト見込み時間または遅延時間を含む。

図８に示される以外の他のデバイスアーキテクチャも実行可能であり、本開示と互換性がある。当業者によって認識されるように、本原理の態様は、システム、方法またはコンピュータ可読媒体として実施されることができる。それによって、本原理の態様は、全ハードウェア実装、（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）全ソフトウェア実装の形式か、または本明細書においてすべて一般的に「回路」、「モジュール」または「システム」として定義されることができるハードウェアとソフトウェアとの態様を組み合わせた実施形態をとることができる。さらに、本原理の態様は、コンピュータ可読記憶媒体の形式をとることができる。１または複数のコンピュータ可読記憶媒体（複数）の任意の組み合わせも利用することができる。

このように、例えば、本明細書に示されたブロック図は、本発明の原理を実施する具体的なシステムコンポーネントおよび／または回路の概念的な図を表すことが当業者によって認識されよう。同様に、フローチャート、フロー図、状態遷移図、疑似コードなどのいずれも、実質的にコンピュータ可読記憶媒体で表され、コンピュータまたはプロセッサによって実施されるさまざまなプロセスを表し、そのようなコンピュータまたはプロセッサが明示的に示されているかどうかを問わないことが当業者によって認識されよう。

コンピュータ可読記憶媒体は、１または複数のコンピュータ可読媒体（複数）において具体化されるコンピュータ可読プログラム製品の形式をとることができ、コンピュータによって実施可能であるコンピュータ可読プログラムコードが具体化される。本明細書で使用されるようなコンピュータ可読記憶媒体は、情報を格納する固有の能力ならびにそこから情報の読み出しを行う固有の能力が与えられた非一時的な記憶媒体と見なされる。コンピュータ可読記憶媒体は、例えば、電子、磁気、光、電子磁気、赤外線、または半導体のシステム、装置、またはデバイスか、または上記の適切な任意の組み合わせとすることができるが、これらに限定されない。以下は、本原理を適用することができるコンピュータ可読記憶媒体のより具体的な例を提供しているが、単に例示であり、余すところのない列挙ではなく、当業者によって容易に認識されるように、ポータブルコンピュータディスケット、ハードディスク、リードオンリーメモリ（ＲＯＭ）、消去可能プログラマブルリードオンリーメモリ（ＥＰＲＯＭまたはフラッシュメモリ）、ポータブルコンパクトディスクリードオンリーメモリ（ＣＤ−ＲＯＭ）、光ストレージデバイス、磁気ストレージデバイス、または上記の任意の適切な組み合わせであることを理解されたい。

Claims (14)

1. ビデオプレーヤデバイス（６１）へのビデオストリーミングの方法であって、
   前記ビデオプレーヤデバイスから、ビデオを前記ビデオプレーヤデバイスにストリーミングするリクエストを受信する（７１）ステップと、
   ビデオをストリーミングする前記リクエストに応答して、前記ビデオプレーヤデバイスに、ビデオを再生するビデオチャンクのリソースロケータを含むビデオチャンクリストを送信するステップ（７２）であって、前記ビデオチャンクリストは、第１のリソースロケータタイプのリソースロケータおよび第２のリソースロケータタイプのリソースロケータを含み、前記第１のリソースロケータタイプは、単一のビデオチャンクを参照し、および前記第２のリソースロケータタイプは、第１のビデオチャンクを参照する第１のリソースロケータと、第２のビデオチャンクを参照する第２のリソースロケータと、前記第２のビデオチャンクのプレイアウト見込み時間とを含む、送信するステップと、
   前記ビデオプレーヤデバイスから、前記ビデオチャンクリストからのビデオチャンクをストリーミングするリクエストを受信する（７３）ステップと、
   ビデオチャンクをストリーミングする前記リクエストに含まれるリソースロケータが前記第１のリソースロケータタイプである場合、前記単一のビデオチャンクを前記ビデオプレーヤデバイスに送信する（７５）ステップと、
   ビデオチャンクをストリーミングする前記リクエストに含まれる前記リソースロケータが前記第２のリソースロケータタイプである場合、前記ビデオプレーヤデバイスに前記第１のビデオチャンクを送信するステップ（７６）と、前記第２のビデオチャンクが利用できない場合、前記第２のビデオチャンクを計算するリクエストを送信する（７８）ステップであって、前記第２のビデオチャンクを計算する前記リクエストは、前記プレイアウト見込みの遅延を含む、送信するステップと、
   を含む、前記方法。
2. 前記第２のビデオチャンクを計算する前記リクエストは、ビデオチャンクの計算をスケジュールするスケジューラ（５０）に送信され、前記スケジューラは、ビデオチャンクを計算するための複数のジョブキュー（５１）を含み、複数のジョブキューのうちの各ジョブキューは、特定のカテゴリのコンピューティングインスタンス（５２）によって提供され、各コンピューティングインスタンスは、計算されたインスタンスをキャッシュメモリ（５４）に格納し、前記スケジューラは、ビデオチャンクを計算するジョブを、関連する前記プレイアウト見込みの遅延に応じて選択された特定のカテゴリのキューに帰属させる、請求項１に記載の方法。
3. 計算する前記リクエストを受信すると、前記スケジューラは、前記第２のビデオチャンクの前記参照に対応するジョブが、計算結果を前記プレイアウト見込みの遅延の範囲内で返す見込みであるかどうかを検証し、返す見込みがない場合、前記第２のビデオチャンクの前記参照に対応する前記ジョブのコピージョブを至急カテゴリのキューに挿入する、請求項２に記載の方法。
4. 計算する前記リクエストを受信すると、前記スケジューラは、前記第２のビデオチャンクの前記参照に対応するジョブが、計算結果を前記プレイアウト見込みの遅延の範囲内で返す見込みであるかどうかを検証し、返す見込みがない場合、前記第２のビデオチャンクの前記参照に対応する前記ジョブを至急カテゴリのキュー内に移動する、請求項２に記載の方法
5. 各ジョブキューをジョブキューサイズに応じて提供するコンピューティングインスタンスを追加または除去するステップさらに含む、請求項２乃至４のいずれかに記載の方法。
6. ジョブキューのカテゴリは、少なくともベストエフォートキューおよび至急キューを含む、請求項２乃至５のいずれかに記載の方法。
7. 前記計算は、ビデオチャンクの画像フレーム内のピクセルゾーンを、前記ビデオプレーヤデバイスのユーザをターゲットにするコンテンツにオーバーレイすることを含む、請求項１乃至６のいずれかに記載の方法。
8. プロセッサ（８０１）と、
   トランスミッタ（８０２）と、
   レシーバ（８０３）と、
   を備えたデバイス（８００、６２）であって、
   前記レシーバは、ビデオプレーヤデバイスから、ビデオを前記ビデオプレーヤデバイスにストリーミングするリクエストを受信するように構成され、
   前記トランスミッタは、ビデオをストリーミングする前記リクエストに応答して、前記ビデオプレーヤデバイスに、リクエストされたビデオのビデオチャンクのリソースロケータを含むビデオチャンクリストを送信するように構成され、前記ビデオチャンクリストは、第１のリソースロケータタイプのリソースロケータおよび第２のリソースロケータタイプのリソースロケータを含み、前記第１のリソースロケータタイプは、単一のビデオチャンクを参照し、および前記第２のリソースロケータタイプは、第１のビデオチャンクを参照する第１のリソースロケータと、第２のビデオチャンクを参照する第２のリソースロケータと、前記第２のビデオチャンクのプレイアウト見込み時間と、を含み、
   前記レシーバは、前記ビデオプレーヤデバイスから、前記ビデオチャンクリストからのビデオチャンクをストリーミングするリクエストを受信するようにさらに構成され、
   前記プロセッサは、ビデオチャンクをストリーミングする前記リクエストに含まれるリソースロケータが前記第１のリソースロケータタイプであるかどうかを判定するように構成され、前記トランスミッタは、ビデオチャンクをストリーミングする前記リクエストに含まれる前記リソースロケータが前記第１のリソースロケータタイプである場合、前記ビデオプレーヤデバイスに、前記単一のビデオチャンクを送信するようにさらに構成され、
   前記プロセッサは、ビデオチャンクをストリーミングする前記リクエストに含まれるリソースロケータが第２のリソースロケータタイプであるかどうかを判定するようにさらに構成され、前記トランスミッタは、ビデオチャンクをストリーミングする前記リクエストに含まれる前記リソースロケータが前記第２のリソースロケータタイプである場合、前記第１のビデオチャンクを前記ビデオプレーヤデバイスに送信するようにさらに構成され、前記プロセッサは、前記第２のビデオチャンクが利用できるか否かを判定するようにさらに構成され、前記トランスミッタは、前記第２のビデオチャンクが利用できない場合、前記第２のビデオチャンクを計算するリクエストを送信するようにさらに構成され、前記第２のビデオチャンクを計算する前記リクエストは、前記第２のビデオチャンクの前記参照および前記プレイアウト見込みの遅延を含む、前記デバイス。
9. 請求項８に記載のデバイス（８００，６１）と、コンピューティングインスタンス（５２）上でビデオチャンクの計算をスケジュールするように構成されたスケジューラ（５０）と、計算されたビデオチャンクを格納するように構成されたキャッシュメモリ（５３）と、を備えたシステムであって、前記デバイスの前記トランスミッタは、前記第２のビデオチャンクを計算する前記リクエストを前記スケジューラに送信するようにさらに構成され、前記スケジューラは、ビデオチャンクを計算する複数のジョブキュー（５１）を格納するメモリを使用し、前記複数のジョブキューのうちの各ジョブキューは、特定のカテゴリのインスタンスのコンピューティングインスタンスによって提供され、各コンピューティングインスタンスは、利用可能な計算されたビデオチャンクを前記キャッシュメモリに格納し、前記スケジューラは、ビデオチャンクを計算するジョブを、関連する前記プレイアウト見込みの遅延に応じて選択された特定のカテゴリのキューに帰属させる、前記システム。
10. 前記スケジューラは、計算する前記リクエストを受信すると、前記第２のビデオチャンクの前記参照に対応するジョブが、計算結果を前記プレイアウト見込みの遅延の範囲内で返す見込みであるかどうかを検証し、返す見込みがない場合、前記第２のビデオチャンクの前記参照に対応する前記ジョブのコピージョブを至急カテゴリのキューに挿入するようにさらに構成される、請求項９に記載のシステム。
11. 前記スケジューラは、計算する前記リクエストを受信すると、前記第２のビデオチャンクの前記参照に対応するジョブが、計算結果を前記プレイアウト見込みの遅延の範囲内で返す見込みであるかどうかを検証し、返す見込みがない場合、前記第２のビデオチャンクの前記参照に対応する前記ジョブを至急カテゴリのキュー内に移動するようにさらに構成される、請求項９に記載のシステム。
12. 前記スケジューラは、各ジョブキューがジョブキューサイズに応じて提供するコンピューティングインスタンスを追加または除去するようにさらに構成される、請求項９乃至１１のいずれかに記載のシステム。
13. 通信ネットワークからダウンロード可能な、および／またはコンピュータによって読み取り可能媒体上で記録された、および／またはプロセッサによって実行可能なコンピュータプログラム製品であって、請求項１乃至７のいずれかに記載の方法のステップを実行するためのプログラムコード命令を含む、前記コンピュータプログラム製品。
14. 非一時的なコンピュータ可読媒体であって、該媒体上に記録されプロセッサにより実行可能なコンピュータプログラム製品を有し、請求項１乃至７のいずれかに記載の方法のステップを実行するプログラムコード命令を含む、前記コンピュータ可読媒体。