(57)【要約】  装置が、第１のメディアストリームを再生している時に、第１のメディアストリームの代わりに第２のメディアストリームの再生を開始する目標時点を決定する。次に、装置は、最小予想遷移期間から最大予想遷移期間までの範囲の時間を要すると予想されるストリーム遷移プロセスを開始し、第２のメディアストリームのタイムリーな再生開始を確実にするのに役立つように、決定された目標時点よりも最大予想遷移期間だけ前に遷移プロセスを開始する。さらに、装置は、第１のメディアストリームから第２のメディアストリームへの遷移を隠すのに役立つように、開始後の最小予想遷移期間から開始後の最大予想遷移期間にわたる不確定期間にわたって遷移フレームシーケンスを生成して再生する。【選択図】図２
2021534698.tif 000002
【特許請求の範囲】
【請求項１】
装置による第１のメディアストリームの再生から第２のメディアストリームの再生への遷移方法であって、
前記装置が、前記第２のメディアストリームの再生を開始する目標時点を決定することと、
前記装置が、前記第１のメディアストリームの再生から前記第２のメディアストリームの再生に遷移する、最小予想遷移期間から最大予想遷移期間までの範囲の期間を要する遷移プロセスを、前記決定された目標時点よりも前記最大予想遷移期間だけ前もって開始することと、
前記装置が、前記第１のメディアストリームから前記第２のメディアストリームへの遷移を隠すのに役立つように、（ｉ）前記開始後の前記最小予想遷移期間から（ｉｉ）前記開始後の前記最大予想遷移期間にわたる不確定期間にわたって遷移フレームシーケンスを生成して再生することと、
を含むことを特徴とする方法。
【請求項２】
前記装置が、前記不確定期間に至る第１のフェード期間にわたって前記第１のメディアストリームから前記遷移フレームへのフェーディングを実行することをさらに含む、
請求項１に記載の方法。
【請求項３】
前記装置が、前記不確定期間の完了時に開始する第２のフェード期間にわたって前記遷移フレームから前記第２のメディアストリームへのフェーディングを実行することをさらに含む、
請求項２に記載の方法。
【請求項４】
前記第１の及び第２のメディアストリームはビデオを含み、前記遷移フレームはブラックフレームを含む、
請求項１に記載の方法。
【請求項５】
前記遷移フレームは、前記第１のメディアストリームの最後に再生されるフレームのコピーをさらに含む、
請求項４に記載の方法。
【請求項６】
前記第１の及び第２のメディアストリームはオーディオを含み、前記遷移フレームは無音フレームを含む、
請求項１に記載の方法。
【請求項７】
前記目標時点を決定することはフィンガープリント分析に基づき、同期ロックを設定すること含む、
請求項１に記載の方法。
【請求項８】
前記第１のメディアストリームの再生から前記第２のメディアストリームの再生への前記遷移はコンテンツ置換のためのものである、
請求項１に記載の方法。
【請求項９】
前記コンテンツ置換は広告置換を含む、
請求項８に記載の方法。
【請求項１０】
装置が、第１のメディアストリームを再生している間に、前記第１のメディアストリームの代わりに第２のメディアストリームの再生を開始すべき目標時点を決定することと、
前記装置が、前記第１のメディアストリームの再生から前記第２のメディアストリームの再生に遷移するストリーム遷移プロセスを開始すべき開始時点を設定することであって、前記遷移の最大予想期間を決定し、前記開始時点を前記決定された目標時点よりも前記最大予想遷移期間だけ前になるように設定することを含むことと、
前記装置が、設定された前記開始時点で前記ストリーム遷移プロセスを開始することと、
前記装置が不確定期間を決定することであって、前記遷移の最小予想期間を決定し、前記不確定期間が（ｉ）前記開始時点の後の前記決定された最小予想遷移期間から（ｉｉ）前記開始時点の後の前記決定された最大予想期間にわたるものとみなすことを含むことと、
前記装置が、前記遷移を隠すのに役立つように、前記決定された不確定期間にわたって一連の遷移フレームを再生することと、
を含むことを特徴とする方法。
【請求項１１】
前記装置が、前記第１のメディアストリームから前記遷移フレームへのフェーディングを追加することをさらに含む、
請求項１０に記載の方法。
【請求項１２】
前記装置が、前記遷移フレームから前記第２のメディアストリームへのフェーディングを追加することをさらに含む、
請求項１０に記載の方法。
【請求項１３】
前記遷移フレームは、（ｉ）ブラックフレーム、（ｉｉ）無音フレーム、及び（ｉｉｉ）前記第１のメディアストリームの最後に再生されるフレームのコピーであるフレームから成る群から選択されたフレームを含む、
請求項１０に記載の方法。
【請求項１４】
前記第１のメディアストリームはリニア放送フィードを含み、前記第２のメディアストリームは置換広告を含む、
請求項１０に記載の方法。
【請求項１５】
前記第１のメディアストリームは置換広告を含み、前記第２のメディアストリームはリニア放送フィードを含む、
請求項１０に記載の方法。
【請求項１６】
前記不確定期間を延長することをさらに含む、
請求項１０に記載の方法。
【請求項１７】
メディアクライアントであって、
プロセッシングユニットと、
非一時的データ記憶装置と、
前記非一時的データストレージに記憶されて、前記プロセッシングユニットが第１のメディアストリームの再生から第２のメディアストリームの再生に遷移する動作を前記メディアクライアントに実行させるために実行できるプログラム命令と、
を備え、前記動作は、
前記第２のメディアストリームの再生を開始する目標時点を決定することと、
前記第１のメディアストリームの再生から前記第２のメディアストリームの再生に遷移する、最小予想遷移期間から最大予想遷移期間までの範囲の期間を要する遷移プロセスを、前記目標時点よりも前記最大予想遷移期間だけ前もって開始することと、
前記第１のメディアストリームから前記第２のメディアストリームへの遷移を隠すのに役立つように、（ｉ）前記開始後の前記最小予想遷移期間から（ｉｉ）前記開始後の前記最大予想遷移期間にわたる不確定期間にわたって遷移フレームシーケンスを生成して再生することと、
を含む、
ことを特徴とするメディアクライアント。
【請求項１８】
前記動作は、前記第１のメディアストリームから前記遷移フレームへのフェーディングを追加することをさらに含む、
請求項１７に記載のメディアクライアント。
【請求項１９】
前記動作は、前記遷移フレームから前記第２のメディアストリームへのフェーディングを追加することをさらに含む、
請求項１７に記載のメディアクライアント。
【請求項２０】
前記遷移フレームは、（ｉ）ブラックフレーム、（ｉｉ）無音フレーム、及び（ｉｉｉ）前記第１のメディアストリームの最後に再生されるフレームのコピーであるフレームから成る群から選択されたフレームを含む、
請求項１７に記載のメディアクライアント。
【発明の詳細な説明】
【技術分野】
【０００１】
〔関連出願との相互参照〕
本出願は、２０１８年１１月７日に出願された米国特許出願第１６／１８３，１８５号、及び２０１８年８月１７日に出願された米国仮特許出願第６２／７６５，１６１号に対する優先権を主張するものであり、これらの各文献はその全体が引用により本明細書に組み入れられる。
【０００２】
本出願は、２０１８年１１月７日に出願された米国特許出願第１６／１８３，２６６号にも関連し、この文献はその全体が引用により本明細書に組み入れられる。
【背景技術】
【０００３】
典型的なメディアクライアントは、ビデオ及び／又はオーディオコンテンツなどのメディアコンテンツを表すアナログ又はデジタルメディアストリームを受け取って再生（例えば、再生のために出力）し、メディアコンテンツの出力及び／又はストリームの転送を行って、ディスプレイ画面及び／又はオーディオスピーカなどのユーザインターフェイス上にコンテンツを提示するように動作する。このようなクライアントの例としては、テレビ、コンピュータモニタ、投影システム、スピーカ、ヘッドフォン、セットトップボックス（例えば、ケーブル又は衛星ＴＶ受信機）、デジタルビデオレコーダ、ラジオ、パーソナルコンピュータ、ゲーム機、ストリーミングメディアプレーヤなどが挙げられる。
【０００４】
一例として、メディアクライアントは、メディアストリーム（例えば、無線放送ストリーム、セットトップボックスからのメディアストリーム出力、デジタル記憶媒体から再生されたメディアストリーム、インターネットストリーム、又は別のこのようなストリーム）を受信して、このストリームのメディアコンテンツをユーザに提示できるテレビとすることができる。別の例として、メディアクライアントは、多チャンネル映像番組配信事業者（ｍｕｌｔｉ−ｃｈａｎｎｅｌ  ｖｉｄｅｏ  ｐｒｏｇｒａｍ  ｄｉｓｔｒｉｂｕｔｏｒ）及び／又はデータストレージから放送ストリームを受け取り、高精細マルチメディアインターフェイス（ＨＤＭＩ(登録商標)）ケーブル又はその他のインターフェイスを介してストリームのメディアコンテンツをテレビ及び／又はオーディオ／ビデオ受信機に出力して再生できるセットトップボックス、或いはデジタルビデオ又はオーディオレコーダとすることもできる。さらに別の例として、メディアクライアントは、ラジオ、コンピュータ、或いは他の受信機又はオーディオ記憶装置からオーディオストリームを受信して、このストリームのオーディオコンテンツをユーザに提示できるスピーカ又はヘッドフォンとすることもできる。他にも数多くの例が考えられる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
いくつかの状況では、メディアクライアントが、メディアストリームの再生中にストリームのメディアコンテンツの一部を置換することが有用な場合がある。例えば、ユーザに対してコンテンツが提示されている時に、ユーザが当初含まれていた広告の代わりに置換広告を受け取るように、クライアントがメディアコンテンツの広告又はその他のセグメントを置換広告又はその他の置換コンテンツに動的に置き換えることが有用な場合がある。
【０００６】
さらに、クライアントがメディアストリーム内の特定の時点でこのようなコンテンツ置換を実行することが望ましい場合もある。例えば、クライアントが既存の広告を置換広告に動的に置き換える場合には、メディアストリーム内で既存の広告が開始した時点でクライアントが置換広告を配置することが望ましいと考えられる。
【０００７】
具体的に言えば、このようなメディアストリームは、ビデオフレーム及び／又はオーディオフレームなどのフレームシーケンスを定めることができ、従ってクライアントはメディアストリームの特定のフレームから開始するコンテンツ置換を実行することが望ましいと考えられる。例えば、広告置換では、クライアントが既存の広告の最初のフレームから開始する置換広告を既存の広告の代わりに挿入することが望ましいと考えられる。
【０００８】
このようなコンテンツ置換を容易にするために、クライアントは、コンテンツ置換を開始すべきメディアストリーム内の特定の時点を学習するとともに、指示された時点でどのような置換コンテンツの再生を開始すべきかを学習することができる。クライアントは、所望のコンテンツ切り替え時点で、既存のメディアストリームを再生することから、置換コンテンツを置換メディアストリームとして再生することに遷移することができる。さらに、クライアントは、置換メディアストリームを再生し終えると、再び（例えば、進行中の）オリジナルメディアストリームの再生に遷移することができる。
【０００９】
このプロセスの１つの技術的困難性は、例えばコンテンツ置換を開始するためにクライアントが第１のストリームの再生から第２のストリームの再生に遷移するのに、或いはコンテンツ置換の終了時に再びオリジナルストリームに切り替えるのにある程度の時間がかかり得る点である。このようなことは、クライアントが第２のストリームの再生を開始できるまでに多くの処理及び多くのメモリを必要とするいくつかのステップに関与する必要が生じ得る際に当てはまる場合がある。例えば、クライアントは、キャッシュをクリアし、第２のストリームのコンテンツの少なくとも最初の部分を受け取って復号し、この復号コンテンツをレンダリングのためにメモリバッファに読み込むことが必要になる場合がある。
【００１０】
実際に、このストリーム遷移プロセスには、１フレームに相当する時間よりも十分に長くかかることがある。例えば、問題のメディアが毎秒３０フレームのフレームレートのビデオである場合、各フレームは１／３０秒、すなわち約３３．３ミリ秒（ｍｓ）に及ぶ。さらに、１つのビデオストリームから別のビデオストリームへの遷移には約数百ミリ秒かかることもあり、従って数多くのビデオフレームと同等の時間に及ぶ。
【００１１】
クライアントは、そのストリーム遷移プロセスを所望のコンテンツ切り替え時点よりも十分に前に開始することによってこのタイミングを考慮するように機能することもできるが、遷移プロセスに要する実際の時間は様々な理由で予測不能な場合がある。従って、クライアントが正確にどれほど早く遷移プロセスを開始すべきかが不明な場合がある。
【００１２】
残念ながら、クライアントは、遷移プロセスを開始するのが早遅すぎた場合、第２のストリームの再生の開始が早くなりすぎるため、所望のコンテンツ切り替え時点の前にプロセスを終了させることによってユーザ体験の問題を引き起こしてしまう恐れがある。また、クライアントは、遷移プロセスを開始するのが遅すぎた場合、第２のストリームの再生の開始が遅くなりすぎるため、所望のコンテンツ切り替え時点までにプロセスを終了させることができず、同様にユーザ体験の問題を引き起こしてしまう恐れがある。
【課題を解決するための手段】
【００１３】
本開示によれば、この問題への対処に役立つように、クライアントが、所望のコンテンツ切り替え時点で第２のストリームの再生を容易に開始するように、ストリーム遷移プロセスを十分に早く開始するように構成できるとともに、遷移を隠して改善されたユーザ体験を提供するのに役立つように、適切な又は望ましい場合にはフェーディングと共に不確定期間にわたって戦略的に遷移フレームを導入する。
【００１４】
クライアントは、所望のコンテンツ切り替え時点で第２のストリームの再生を容易に開始するために、（例えば、過去の経験又は実験、又は予め提供された設定から）最大予想遷移期間がどれほどになり得るかを決定した後に、所望のコンテンツ切り替え時点よりもこの決定された最大予想遷移期間だけ前の時点ＴSTARTにおいてストリーム遷移プロセスを開始することができる。クライアントは、この時点でストリーム遷移プロセスを開始すれば、所望のコンテンツ切り替え時点である時点ＴMAXまでにストリーム遷移プロセスを最適に終了するはずである。
【００１５】
さらに、クライアントは、（同様に過去の経験又は実験、又は予め提供された設定から）最小予想遷移期間がどれほどになり得るかも決定することによって、ストリーム遷移プロセスの開始時点からの最小予想遷移期間である時点ＴMINを識別することができる。これを踏まえれば、クライアントは、ＴMINからＴMAXまでの時間範囲内のどの時点でもストリーム遷移プロセスを終了させることができるので、この範囲を不確定期間とみなすことができる。
【００１６】
クライアントは、ストリーム間の遷移を隠すのに役立つように、不確定期間、すなわちＴMINからＴMAXまでの継続期間にわたって遷移フレームを再生することができる。これらの遷移フレームは、問題のメディアのタイプに応じて様々な形態を取ることができる。例えば、メディアがビデオを含む場合、遷移フレームはブラックフレームを含むことができる。一方で、メディアがオーディオを含む場合、遷移フレームは無音フレームを含むことができる。さらに、クライアントは、第１のストリームから遷移フレーム入るまでに、及びその後の遷移フレームから第２のストリームまでにフェーディングを追加することもできる。
【００１７】
従って、このプロセスは、上述した関連するユーザ体験問題を最小化又は回避しながら、１つのストリームから別のストリームへの時間的に正確な切り替えを容易にするのに役立つことができる。
【００１８】
必要に応じて添付図面を参照しながら以下の詳細な説明を読むことにより、当業者にはこれらの及びその他の態様、利点及び代替例が明らかになるであろう。さらに、本概要の説明及び後述する説明は、本発明を限定ではなく一例として示すものにすぎないと理解されたい。
【図面の簡単な説明】
【００１９】
【図１】開示する特徴を実装できるシステムの簡略ブロック図である。
【図２】本開示による、遷移フレームの追加を伴うストリーム遷移を示す図である。
【図３】本開示に従って実行できる方法を示すフローチャートである。
【図４】本開示に従って実行できる方法を示す別のフローチャートである。
【図５】本開示に従って動作できるメディアクライアント例のコンポーネントを示す簡略ブロック図である。
【発明を実施するための形態】
【００２０】
図面を参照すると、図１は、開示する様々な原理を適用できるシステム例の簡略ブロック図である。しかしながら、本明細書で説明するこの及びその他の構成及びプロセスは他の様々な形態を取ることもできると理解されるであろう。例えば、要素及び動作は、並べ替え、分散させ、置換し、組み合わせ、省略し、追加し、又は別様に修正することができる。さらに、本明細書において１又は２以上のエンティティによって実行されるものとして説明する動作は、これらのエンティティが実行することも、及び／又はこれらのエンティティの代わりにプログラム命令を実行する１又は２以上のプロセッシングユニットなどがハードウェア、ファームウェア及び／又はソフトウェアを通じて実行することもできると理解されるであろう。
【００２１】
図１に示すように、このシステム例は、メディアソース１４からリアルタイムでメディアストリームを受け取るように構成されたメディアクライアント１２を含む。
【００２２】
メディアクライアント１２は、上述したように、ビデオ及び／又はオーディオコンテンツなどのメディアコンテンツを表すアナログ又はデジタルメディアストリームをメディアソース１４から受け取り、メディアコンテンツの出力及び／又はストリームの転送を行って、ディスプレイ画面及び／又はオーディオスピーカなどのユーザインターフェイス上にコンテンツを提示するように動作するよう構成することができる。メディアクライアントは、数ある可能性の中でも特に上述した形態のうちのいずれかを取ることができる。
【００２３】
メディアソース１４は、場合によってはメディアクライアント１２の形態に依存する様々な形態を取ることもできる。一例として、メディアクライアント１２がテレビである場合、メディアソース１４は、選択されたメディアストリームを出力してテレビが提示できるように構成されたローカルセットトップボックス（例えば、ケーブル又は衛星受信機）又はストリーミングメディアサーバとすることができ、或いはメディアソース１４は、数ある可能性の中でも特に放送テレビ局などとすることもできる。また、メディアクライアントがコンピュータである場合、メディアソースは、インターネットストリーミングメディアサーバ又はその他のメディアプロバイダを含むことができる。或いは、メディアソース１４は、メディアクライアント１２に一体化された、及び／又はメディアクライアント１２がメディアストリームの再生中又は再生のための転送中などに再生のためにローカルにアクセスしてメディアストリームを受け取る（例えば、取り出す）ことができるデータストレージとすることもできる。その他の例も考えられる。
【００２４】
さらに図１に示すように、メディアクライアント１２は、１又は２以上のサーバ１８との通信を可能にするネットワーク（例えば、インターネット又はプライベートネットワーク）１６との通信インターフェイスを有することができる。サーバ１８は、ファイルサーバ、メディアサーバ、及び／又は他のタイプのコンテンツサーバなどを含むことができる。さらに、メディアソース１４は、サーバ１８とは別に示しているが、１又は２以上のサーバ１８と共に含め又は一体化して、ネットワーク１６を介してアクセスすることもできる。
【００２５】
上述したように、クライアント１２などのメディアクライアントは、メディアストリームを受け取って再生（例えば、再生のために出力）している時に、ストリームの一部を、置換ストリームを定める置換コンテンツに置き換えることが有用な場合がある。さらに、上述したように、クライアントは、メディアストリーム内の特定の時点でこれを行うことが望ましい場合がある。例えば、ストリームがビデオフレーム及び／又はオーディオフレームなどのフレームシーケンスを定める場合、クライアントは、シーケンスの特定のフレームから開始するコンテンツ置換を実行することが望ましい場合がある。
【００２６】
実際に、クライアントは、コンテンツ置換を開始すべきメディアストリーム内の特定の目標時点を様々な方法で学習（決定）することができる。
【００２７】
例えば、クライアントは、メディアストリームと共に又はこれに関連して、メディアストリーム内の各フレームを識別する又はこれにタイムスタンプする（例えば、メディアストリームにタイムスタンプが埋め込まれた、又はストリーム内シグナリングを通じて別様にタイムスタンプが提供された）データセットと、コンテンツ置換を開始すべきフレームの識別子又はタイムスタンプを指定するデータとを提供され又は受け取ることができる。従って、クライアントは、このデータに基づいて、コンテンツ置換を開始すべきメディアストリーム内の特定の時点を決定することができる。
【００２８】
或いは、クライアントは、メディアストリームを受け取って再生する際に、ネットワークサーバと協働して、コンテンツ置換を開始すべきメディアストリーム内の時点を所望のコンテンツ切り替え時点として学習することもできる。例えば、サーバは、最初に、クライアントが再生しているメディアストリームを識別することができる。サーバは、メディアストリームを識別すると、クライアントがコンテンツ置換を開始すべきメディアストリーム内の特定の時点を決定し、この決定された時点をクライアントに通知することができる。
【００２９】
クライアント（又は付属装置）は、クライアントが再生しているメディアストリームをサーバが容易に識別できるように、ストリームを受け取る際にメディアコンテンツを表すデジタルフィンガープリントデータをリアルタイムで生成することができ、サーバは、このフィンガープリントデータと、既知のメディアストリームのメディアコンテンツを表す基準フィンガープリントデータとを比較し、フィンガープリントが一致した場合、クライアントが再生しているメディアストリームが既知のメディアストリームであることを示すことができる。
【００３０】
サーバは、既知のメディアストリームを表す基準フィンガープリントデータを確立又は別様に入手することができる。例えば、サーバ又は関連する視聴ステーション（ｗａｔｃｈｉｎｇ  ｓｔａｔｉｏｎ）又はその他のエンティティは、既知のメディアストリームのブロードキャストを受け取り、その最中に既知のメディアストリームのフレームを表す基準デジタルフィンガープリントシーケンスを生成することができる。サーバ又は別のエンティティは、既知のメディアストリームのフレームをプログラム的に分析し、既知のメディアストリームのコピーを入力として受け取り、現在知られている又は後で開発されるメディアフィンガープリンティングプロセス又はアルゴリズムを適用して基準フィンガープリントを生成することによって、これらの基準フィンガープリントを確立することができる。或いは、サーバは、この既知のメディアストリームを表す基準フィンガープリントシーケンスを別様に確立し又は提供されることもできる。その後、サーバは、基準フィンガープリントを既知のメディアストリームの識別子と関連付けて記憶することができる。
【００３１】
さらに、クライアントは、メディアストリームを再生する際に、このストリームのフレームを表すクエリフィンガープリントをリアルタイムで生成して、分析のためにサーバに送信することができる。クライアントは、フィンガープリントの比較を容易にするために、基準フィンガープリントを確立するために適用する又は適用した同じフィンガープリンティングプロセス又はアルゴリズムを使用してこれらのクエリフィンガープリントを生成することができる。また、クライアントは、特定のフレームレートでクエリフィンガープリントを生成し、これらのフィンガープリントをまとめてサーバに送信することもできる。例えば、毎秒３０フレームのビデオを含むメディアストリームの場合、クライアントは、リソースの節約に役立つように毎秒約２フレームの低フレームレートでクエリフィンガープリントを生成し、最新の一群のクエリフィンガープリントを１．５秒毎程度でサーバに送信することができる。その他の例も考えられる。
【００３２】
サーバは、クライアントからクエリフィンガープリントデータを受け取ると、クエリフィンガープリントデータを既知のメディアストリームの基準フィンガープリントデータと比較することができる。そして、サーバは、この比較によってクエリフィンガープリントデータが基準フィンガープリントデータに一致すると十分な信頼度で判定した場合、クライアントが再生しているメディアストリームが既知のメディアストリームであると結論付けることができる。
【００３３】
サーバは、このフィンガープリント比較をフレーム毎に実行することができる。例えば、ビデオコンテンツについて考察すると、サーバは、フレームのクエリフィンガープリントをフレームの基準フィンガープリントと比較する分析をビデオフレーム毎に実行することができる。この比較プロセスは、フィンガープリントの構造に応じて様々な形態のうちのいずれかを取ることができる。例えば、この比較は、フィンガープリント間の最大偏差を計算し、最大偏差が所定の許容差内に収まるかどうかを判定することを含むことができる。さらに、フィンガープリントが２進値である場合、この判定は、ブール型の判定とすることも、又は（フィンガープリントのそれぞれのビット位置間の不一致数としての）ハミング距離の計算を伴うこともできる。フィンガープリントが１０進値又はベクトル（例えば、ビデオフレーム領域毎のグレイ値）などのより複雑な値である場合、この判定は、値又はベクトル間の距離を求めることを含むことができる。他にも数多くの例が考えられる。
【００３４】
また、サーバは、このフィンガープリント比較プロセスを所望の許容差レベルで実行することもできる。例えば、この比較は、より多くの数の相違を認める許容差及び／又はより大きなサイズの相違を認める許容差などの、フィンガープリント間の相違の許容差が比較的大きな粗いものとすることができる。一例として、２つの３２ビットのフィンガープリントを互いに比較する場合、たとえ２つの又は別の指定数のビットが一致しない場合でも、粗い比較では、これらのフィンガープリントを互いに大まかに一致するとみなすことができる。或いは、この比較は、このような相違の許容差が小さい、及び／又は根本的なメディアの特定の部分を表すと思われる特定のフィンガープリント成分に比較の焦点を当てた、より粒度の細かいものとすることもできる。
【００３５】
これにより、サーバは、このクライアントが生成したクエリフィンガープリントと既知のメディアストリームの基準フィンガープリントとの比較を通じて１又は２以上の一致を発見することができる。例えば、サーバは、クライアントが再生しているメディアストリームのフレームのクエリフィンガープリントが既知のメディアストリームのフレームのそれぞれの基準フィンガープリントに一致する１又は２以上の場合を発見することができる。従って、この一致は、クライアントが再生しているメディアストリームが既知のメディアストリームであるとの結論を立証又は支援することができる。
【００３６】
或いは、サーバは、問題のメディアストリームを他の方法で識別することもできる。例えば、メディアストリームが、メディアストリームの素性に対応するウォーターマークデータを含む場合、クライアントは、このウォーターマークデータを読み取り又は別様に抽出してサーバにウォーターマークデータを報告することができる。すると、サーバは、報告されたウォーターマークデータを基礎として使用して、クライアントが受け取っているメディアストリームを識別することができる。例えば、サーバは、様々なウォーターマークデータを特定の既知のメディアストリームに相関させる基準データを調べて、クライアントによって報告されたウォーターマークデータが特定の既知のメディアストリームに一致すると判定することができる。
【００３７】
サーバは、クライアントが再生しているメディアストリームを識別し終えると、コンテンツ置換を行うべきメディアストリーム内の時点を決定することができる。例えば、サーバは、コンテンツ置換を開始すべき既知のメディアストリーム内の時点を指定する基準データを参照することができる。その後、サーバは、この時点を示す指令をクライアントに送信することができる。
【００３８】
サーバの基準データによって指定される置換時点は、クライアントが理解できる形で定めることができる。例えば、メディアストリーム内に定められた「実時間」タイムラインに沿ってメディアストリームの各フレームにタイムスタンプするデータをクライアントが提供される場合、サーバが有する置換時点は、メディアストリームの次のフレームの実時間タイムスタンプとすることができる。従って、サーバは、この実時間タイムスタンプを、クライアントがコンテンツ置換を開始すべき時間の指標としてクライアントに提供することができる。
【００３９】
さらに、クライアントは、コンテンツ置換を開始すべき時点を自機のクロック上で決定できるように、この実時間タイムスタンプをクライアントの内部クロックに従って定められた「クライアント時間」に対応付けることができる。例えば、クライアントは、（ｉ）現在のフレームの実時間タイムスタンプとクライアントのクロック上の現在時刻との間の差分を計算し、（ｉｉ）この求められた差分を、置換を行うべき次のフレームの指示された実時間タイムスタンプに適用して、コンテンツ置換を開始すべきクライアント時間時点を決定することができる。
【００４０】
或いは、サーバの基準データによって指定される置換時点は、クライアントが理解できない方法で定めることもできる。例えば、サーバが有する置換時点は、既知のメディアストリーム内の実時間タイムラインに従って定められたタイムスタンプであるが、実時間のコンテキスト又は観点をクライアントが有していないこともある。この場合、サーバは、実時間とクライアント時間との間のマッピング又は「同期ロック」を確立するプロセスを行った後に、コンテンツ置換を行うべき実時間時点を対応するクライアント時間時点に対応付け、このクライアント時間時点をクライアントに提供することができる。
【００４１】
この非限定的な例として、テレビ放送内に出現し得る広告ポッドを定めるメディアストリームについて考察する。広告ポッドは、テレビコマーシャルなどの広告シーケンスを含む。この例では、特定のテレビチャンネルのリニア放送フィード（ｌｉｎｅａｒ  ｂｒｏａｄｃａｓｔ  ｆｅｅｄ）を受信して再生しているテレビをクライアントとすることができ、このフィード内のあらゆる瞬間に広告ポッドが現れることができる。例えば、特にスポーツイベントなどのライブ放送では、このようなフィード内に広告ポッドが現れる時間を予測できないこともある。或いは、特別にスケジュールされた時点に広告ポッドが現れることもある。
【００４２】
この例では、広告ポッド内の特定の広告の置換（例えば、広告を異なる広告又はその他の置換コンテンツに置き換えること）を望ましいコンテンツ置換とすることができる。例えば、広告ポッドが広告シーケンスＡ１、Ａ２、Ａ３、Ａ４である場合、広告Ａ３の置換を望ましいコンテンツ置換とすることができる。
【００４３】
この状況では、広告ポッドが、Ｔ＝０の時点から開始して広告ポッドの最後まで継続する内部タイムラインを定めることができ、広告Ａ３は、このタイムライン上の時点ＴＡ３から開始することができる。しかしながら、クライアントにはこのタイムラインのコンテキストが存在しないことがある。クライアントは、クライアント時間を定めるタイムライン（例えば、時刻又はその他の内部時間基準）を有する独自の内部クロックを有することができる。しかしながら、クライアントは、クライアント時間内のどこに広告ポッドタイムラインが存在するかについての高度な知識を有していなければ、望ましいコンテンツ修正時点としての値ＴＡ３のみを与えられても、望ましい時に広告置換を開始することはできない。
【００４４】
クライアントは、このコンテキストでサーバが実時間とクライアント時間との間の同期ロックを確立できるように、サーバに送信するクエリフィンガープリントにタイムスタンプすることができる。具体的に言えば、クライアントは、メディアストリームを再生してクエリフィンガープリントを生成する際に、各クエリフィンガープリントに現在のクライアント時間値をタイムスタンプすることができる。サーバは、クエリフィンガープリントと既知のメディアストリームのタイムスタンプ付き基準フィンガープリントとの間の１又は２以上の一致を検出すると、これらの一致点を基礎として使用して実時間をクライアント時間に対応付けることができる。例えば、サーバは、少なくとも１つのこのような検出された一致点に基づいて、（ｉ）照合用基準フィンガープリントの実時間タイムスタンプと、（ｉｉ）照合用クエリフィンガープリントのクライアント時間タイムスタンプとの間のマッピングを定めることができる。
【００４５】
サーバは、同期ロックを確立し終えると、この確立された同期ロックを使用して、コンテンツ置換を行うべき実時間時点を、コンテンツ置換を行うべき対応するクライアント時間時点に変換することができる。サーバは、クライアントが再生しているメディアストリーム内の所望の時点でクライアントがコンテンツ置換を開始できるように、この決定されたクライアント時間時点をクライアントに送信することができる。
【００４６】
さらに、別の実装では、コンテンツ置換を行うべきクライアント時間時点を決定するために、同期ロックを確立して適用するプロセスをサーバではなくクライアントが実行することができる。
【００４７】
例えば、サーバは、クライアントが受け取っているメディアストリームを識別すると、基準フィンガープリントを定める何らかの基準データと、既知のメディアストリームの次の部分の実時間タイムスタンプとをクライアントに送信することができる。すると、クライアントは、クエリフィンガープリントと基準フィンガープリントとの間のフィンガープリント照合を実行して１又は２以上の一致点を発見し、少なくとも１つの一致点のタイムスタンプを同様に相関させることによって実時間とクライアント時間との間の同期ロックを確立することができる。クライアントは、同期ロックを確立し終えると、この同期ロックを基礎として使用して、コンテンツ置換を行うべき提供された実時間時点を、コンテンツ置換を行うべき対応するクライアント時間時点に変換することができる。
【００４８】
クライアントは、コンテンツ置換を開始すべきメディアストリーム内の目標時点を決定することに加え、その時点から開始してどのコンテンツ置換を実行すべきかを様々な方法で学習することもできる。
【００４９】
一例として、クライアントは、メディアストリームの既存のコンテンツの代わりに特定のコンテンツを代替すべき旨の指示などの指示が行われた時点で、開始すべきコンテンツ置換の明細を予め提供されることができる。或いは、クライアントは、実行すべきコンテンツ置換の明細をサーバ又はその他のエンティティから受け取ることもできる。例えば、サーバは、クライアントがコンテンツ修正を開始すべきメディアストリーム内の時点をクライアントに知らせる指令をクライアントに送信する際に、実行すべきコンテンツ置換の明細をこの指令に含める（又は別個に提供する）ことができる。
【００５０】
実際に、実行すべきコンテンツ置換の明細は、クライアントがメディアストリームの既存のコンテンツの代わりに又はその補完として取得して挿入すべき置換コンテンツへのポインタを含むことができる。例えば、上述したように、この明細は、クライアントが置換コンテンツの要求及び受信を行うことができるストリーミングメディアサーバ又はファイルサーバなどのネットワークアドレスを定める又はこれと相関するユニバーサルリソースロケータ（ＵＲＬ）を含むことができる。或いは、この明細は、メディアストリーム内の指示された時点でコンテンツ置換の開始を容易に実行できるように、置換コンテンツを取得すべき場所及び／又は方法を別の方法で示すこともできる。さらに、この明細は、クライアントがオリジナルコンテンツの代わりにどれほどの期間にわたって置換コンテンツを再生すべきであるかをクライアントに知らせるように、置換コンテンツの期間を示すこともできる。
【００５１】
クライアントは、指示されたコンテンツ置換を開始すべき時点で、既存のメディアストリームを再生することから、置換コンテンツを置換メディアストリームとして再生することに切り替えることができる。さらに、クライアントは、コンテンツ置換の終了時に、再び（例えば、進行中の）オリジナルメディアストリームを再生することに切り替えることができる。
【００５２】
非限定的な例として、上述した広告ポッドについて再び考察する。実際に、サーバは、広告ポッドのフレームを表してこれに対応するタイムスタンプ付き基準フィンガープリントを提供されることができる。さらに、サーバは、広告ポッド内の広告のうちの特定の１つを置換すべき旨の指示と、この広告置換を容易にするための情報とを取得することができる。例えば、サーバは、既存の広告の第１のフレームの実時点の指示と、置換広告のＵＲＬと、置換期間の指示とを提供されることができる。
【００５３】
クライアントは、この広告ポッドを含むことができるリニア放送フィードを受け取って再生する際に、継続的に、或いは１又は２以上の他のトリガに応答して、放送フィードのタイムスタンプ付きクエリフィンガープリントを生成してこれらのタイムスタンプ付きクエリフィンガープリントを分析のためにサーバに報告することができる。サーバは、このようなクエリフィンガープリントと、広告ポッドシーケンスのフレームを表す基準フィンガープリントとを比較することによって、クライアントが広告ポッドシーケンスを再生していることを検出することができる。
【００５４】
サーバは、クライアントが広告ポッドシーケンスを再生していると判定すると、例えば上述した方法で、広告置換を開始すべきフレームの実時点を対応するクライアント時間時点に変換するとともに、クライアント時間時点を指定し、そのクライアント時間から開始してメディアストリームのフレームの代用とすべき置換広告へのポインタを含み、指示されたコンテンツ置換を実行するようにクライアントに指示する指令をクライアントに送信することができる。従って、クライアントは、指示された置換広告を取得し、指示されたクライアント時間時点から開始してこの広告をメディアストリームのフレームの代用とすることができる。
【００５５】
さらに、サーバは、広告置換の期間、又は広告置換を終了すべきクライアント時間時点をクライアントに知らせることができ、或いは、この期間は標準的な又は予め確立された期間とすることもできる。その後、クライアントは、広告置換の終了時に、置換広告の再生から進行中の放送フィード（例えば、残りの広告ポッドシーケンス）の再生に再び切り替えることができる。
【００５６】
上述したように、このプロセスで発生し得る技術的課題は、クライアントがリニア放送ストリーム内の広告ポッドシーケンスを再生することから置換広告ストリームを再生することなどの、１つのストリームの再生から別のストリームの再生への遷移にある程度の時間がかかり得る点である。具体的に言えば、上述したように、クライアントは、置換ストリームの再生開始を容易にするために、キャッシュをクリアし、コンテンツを受け取って復号し、メモリバッファへの読み込みを行うことなどの様々なプロセスに関与する必要がある。
【００５７】
このストリーム遷移プロセスの開始点は、様々な方法で定めることができる。例えば、クライアントがストリーミングメディアサーバから第２のストリームのコンテンツを受け取る場合、ストリーム遷移プロセスの開始は、数ある可能性の中でも特に、クライアントが最初の伝送制御プロトコル（ＴＣＰ）ハンドシェイクメッセージを送信してサーバとのＴＣＰセッションの確立を開始した時点、或いはクライアントがサーバとのリアルタイムトランスポートプロトコル（ＲＴＰ）セッションの確立を開始するためにリアルタイムストリーミングプロトコル（ＲＴＳＰ）ＳＥＴＵＰ要求などを送信した時点とすることができる。或いは、クライアントが別様に又は別のソースから第２のストリームのコンテンツを受け取る場合には、プロセスの開始点を他の方法で定めることもできる。プロセスの終了は、クライアントがジッタ及び／又はその他の問題を考慮しながらストリームの再生を開始するのに十分な量の第２のメディアストリームをバッファリングし終えた時点として定めることができる。その他の例も考えられる。
【００５８】
上述したように、ストリーム遷移プロセスは、開始から終了まで約数百ミリ秒かかることがある。さらに、リソース制約及びその他の要因は時間と共に変化するので、いずれかの所与の段階でクライアントが１つのストリームから別のストリームに遷移するのにかかる実際の時間は予測することができない。
【００５９】
クライアントの（又は代表的なクライアントの）最小及び最大予想ストリーム遷移期間は、体験的に定めることができる。例えば、クライアントが第１のストリームの再生から第２のストリームの再生（例えば、クライアントが第２のストリームの再生を開始する準備が整った時点）に遷移するのに３００ｍｓ〜５００ｍｓ程度の時間がかかるとの試験結果が示されたこともある。従って、クライアントは、３００ｍｓの最小予想切り替え期間と５００ｍｓの最大予想遷移期間とを有し、数ある可能性の中でも特に２００ｍｓの不確定範囲を定めることができる。
【００６０】
クライアントは、一定期間にわたってストリーム遷移期間を追跡し、追跡期間をまとめ上げて最小値及び最大値の統計的尺度を確立することによってこれらの最小及び最大予想ストリーム遷移期間を決定することができ、及び／又は予想遷移期間の代表値を別様に提供されることもできる。
【００６１】
クライアントは、ストリーム遷移プロセスに最大予想遷移期間よりも長い時間はかからないはずであるとの予想を踏まえて、そのストリーム遷移プロセスを所望のコンテンツ切り替え時点よりも最大予想遷移期間に等しい時間だけ前もって開始するように構成することができる。このように、クライアントは、所望のコンテンツ切り替え時点が訪れる時点までにストリーム遷移プロセスを完了すべきである。
【００６２】
ところが残念ながら、クライアントは、第２のストリームを再生する準備が終わると、この時点で第１のストリームのコンテンツではなく第２のストリームのコンテンツを再生のためにバッファリングしていると考えられるので、もはや第１のストリームを十分に再生できる状態にない可能性がある。従って、クライアントは、最大予想切り替え期間の最後が経過する前に第２のストリームの再生準備を終えた場合、所望のコンテンツ切り替え時点の前に第２のストリームの再生を開始してしまい、これによってユーザ体験の問題が発生することがある。さらに、広告置換などのコンテンツ置換の場合、このように第２のストリームの再生開始が早すぎると、クライアントが第２のストリームの再生から第１のストリームの再生に再び切り替える置換期間の最後に、関連するユーザ体験の問題が発生することがある。
【００６３】
クライアントに望ましい時点よりも早く第２のストリームの再生を開始させるのを回避するのに役立つ１つの方法は、代わりにクライアントが、そのストリーム遷移プロセスを所望のコンテンツ切り替え時点よりも最大予想遷移期間に満たない時間だけ前に開始するように構成することである。例えば、クライアントは、最大予想遷移期間未満ではあるが最小予想遷移期間以上の時間だけ所望のコンテンツ切り替え時点よりも前にストリーム遷移プロセスを開始することができる。
【００６４】
ただし、クライアントがそのストリーム遷移準備を終えるのが遅すぎ、すなわち所望のコンテンツ切り替え時点の経過後になることもあるので、この解決策が最適というわけでもない。この場合、クライアントは、置換されるはずの基本コンテンツの一部を結局再生した後に突然置換コンテンツの再生に切り替えることによってユーザ体験を低下させてしまうこともある。或いは、この解決策では、クライアントが第２のストリームの再生の準備を終えるのが早すぎて（所望のコンテンツ切り替え時点よりも前になって）、やはり上述したようなユーザ体験問題を引き起こしてしまうこともある。
【００６５】
上述したように、クライアントは、この技術的課題への対処に役立つように、そのストリーム遷移プロセスのタイミングを所望のコンテンツ切り替え時点で第２のストリームの再生が容易に開始されるように構成できるとともに、遷移を隠して改善されたユーザ体験を提供するのに役立つように、適切な場合にはフェーディングと共に不確定期間にわたって戦略的に遷移フレームを導入する。
【００６６】
具体的に言えば、クライアントは、そのストリーム遷移プロセスを所望のコンテンツ切り替え時点よりも最大予想切り替え期間（例えば、５００ｍｓ）だけ前もって開始することができ、これによって所望のコンテンツ切り替え時点で第２のストリームの再生を開始できるようになるはずである。さらに、クライアントは、所望のコンテンツ切り替え時点が訪れる前に（すなわち、最大予想切り替え期間が過ぎる前に）第２のストリームの再生準備を終わらせる可能性に対処するのに役立つように、（ｉ）ストリーム遷移プロセスの開始後の最小予想遷移期間から（ｉ）ストリーム遷移プロセスの開始後の最大予想遷移期間までの不確定期間全体を通じて戦略的に遷移フレームを再生する。
【００６７】
実際には、不確定期間を通じてクライアントが再生する遷移フレームは、問題のメディアのタイプに基づいて様々な形態を取ることができる。
【００６８】
例えば、メディアがビデオを含む場合、遷移フレームは、ブラックフレーム及び／又は遷移直前のフレームのコピーを含むことができる。具体的に言えば、クライアントは、不確定期間の継続時間にわたってブラックフレームを提示することができ、場合によっては不確定期間の開始までにブラックフレームに達するように第１のストリームからブラックフレームにフェーディングさせ、場合によっては第２のストリームの再生が開始する時点又はその前後に（例えば、所望のコンテンツ切り替え時点に）開始してブラックフレームから第２のストリームにフェーディングさせることができる。或いは、クライアントは、不確定期間に入ってしばらくの間、第１のストリームの最新フレームのコピーであるフレームを提示し、その後にこの画像からブラックフレームにフェーディングさせ、所望のコンテンツ切り替え時点で再び第２のストリームにフェーディングさせることもできる。
【００６９】
一方で、メディアがオーディオを含む場合、遷移フレームは無音フレームを含むことができる。具体的に言えば、クライアントは、不確定期間の継続時間にわたって無音フレームを提示することができ、場合によっては不確定期間の開始までに無音フレームに達するように第１のストリームのオーディオから無音フレームにフェーディングさせ、場合によっては無音フレームから所望のコンテンツ切り替え時点に開始する第２のストリームのオーディオにフェーディングさせることができる。これらの例の組み合わせ及び変形例を含む他の例も可能である。
【００７０】
図２は、左から右に時間が進むタイムラインに沿ってこのプロセスが実際にどのように機能できるかについての例を制限なく示す図である。図２に示すように、時点ＴSWITCHは、所望のコンテンツ切り替え時点を示す。例えば、広告ポッドを含むリニア放送フィードをクライアントが受け取っている時には、クライアントが広告ポッド内の広告の代わりに置換広告の再生を開始すべきクライアント時間時点を時点ＴSWITCHとすることができる。一般に、クライアントは、最初に第１のメディアストリーム（例えば、リニア放送フィード）２２を再生しており、時点ＴSWITCHにおいて、第１のメディアストリーム２２を再生することから代わりに第２のメディアストリーム（例えば、置換広告ストリーム）２４を再生することに切り替える。
【００７１】
この例は、クライアントが第１のメディアストリーム２２を受け取って再生することから第２のメディアストリーム２４を受け取って再生することに切り替えるのに３００ｍｓ〜５００ｍｓ程度の時間がかかることを前提とする。従って、上記の説明によれば、クライアントは、この切り替えプロセスを所望のコンテンツ切り替え時点ＴＳWITCHの５００ｍｓ前に開始することができる。図２には、この切り替えプロセス開始時点を時点ＴＳTARTとして示す。さらに、この図には、最小及び最大予想切り替え期間ＴMIN及びＴMAXをそれぞれ切り替えプロセス開始時点ＴSTART後３００ｍｓ及び５００ｍｓとして示し、ＴMINからＴMAXまでの２００ｍｓの不確定期間２６を定めており、ＴMAXはＴSWITCHに等しい。このタイムラインでは、クライアントが、ストリーム遷移プロセスを開始すると、時点ＴSWITCHにおいて第２のストリーム２４の再生を開始できるように、第２のストリーム２４の再生準備をこの不確定期間内のどこかの時点で完了する可能性が高いと予想される。
【００７２】
この例では、クライアントが、第１のストリームから第２のストリームへの遷移を隠すのに役立つように、不確定期間、すなわちＴMINからＴMAXまでの継続時間にわたって遷移フレームを再生する。図２には、この遷移フレームシーケンスをシーケンス２８として示す。さらに、この図には、ＴMINにおいて終了する第１のメディアストリーム２２の再生、ＴMINからＴMAXまで行われる遷移フレームの再生、及びＴMAX（すなわち、ＴＳWITCH）において開始する第２のメディアストリーム２４の再生を示す。
【００７３】
さらに図示のように、クライアントは、第１のメディアストリーム２２から遷移フレームへの、及びその後の遷移フレームから第２のメディアストリームへのフェーディングを追加することもできる。クライアントは、これを容易にするために、遷移フレームシーケンス２８をＴMINよりもフェード期間３０分だけ前に開始してＴMAX後にもフェード期間２２にわたって継続するように拡大することができる。従って、図示のように、クライアントは、フェード期間３０全体を通じて第１のメディアストリーム２２及び遷移フレームの両方を提示して第１のメディアストリーム２２から遷移フレームにフェーディングさせる。同様に、クライアントは、フェード期間３２全体を通じて遷移フレーム及び第２のメディアストリーム２４の両方を提示して遷移フレームから第２のメディアストリームにフェーディングさせる。
【００７４】
クライアントは、ブラックフレーム、無音フレーム及びフェードイン／アウトを導入する固有の機能を有するように構成することができる。クライアントは、この機能を利用してこのプロセスを容易にすることができる。例えば、ブラックフレームを導入するには、クライアントが各フレームを完全に黒色の画像として生成し、このフレームを再生のために出力することによってディスプレイなどのユーザインターフェイス上にブラックフレームを提示することができる。同様に、無音フレームを導入するには、クライアントが各フレームをゼロレベルのオーディオで生成し、このフレームを再生のために出力することによってサウンドスピーカなどのユーザインターフェイス上に無音を提示することができる。また、フェードイン及びフェードアウトを導入するには、クライアントがディゾルブアルゴリズムをプログラム的に適用し、画像及び／又はオーディオ間のモーフィングを行うフレームを生成することができる。
【００７５】
上述したように、問題のメディアがビデオである限り、単にブラックフレームを遷移として再生することに代わる１つの方策は、第１のメディアストリーム２２の最後に提示されるフレームのコピーであるフレームをクライアントが再生することである。例えば、クライアントは、フェード期間３０の開始時に第１のメディアストリーム２２の現在のフレームの静止画像を取り込むことができる。次に、クライアントは、この静止画像をフェード期間２８中に反復フレーム内で提示し、従ってこの静止画像から黒色にフェーディングさせることができる。或いは、クライアントは、ブラックフレーム又は第１のメディアストリームの最後のフレームの画像に限らず他のタイプの画像又は色を遷移フレームとして提示することもできる。
【００７６】
従って、このプロセス例では、不確定期間２６中のどこかでクライアントが切り替え準備を完了する可能性が高くなる。その後、クライアントは、所望のコンテンツ切り替え時点ＴSWITCHまで待ってから第２のメディアストリーム２４の再生を開始することができる。クライアントは、遷移を隠すのに役立つように当分の間遷移フレームを再生する。
【００７７】
なお、広告ポッド内の広告の置換などのコンテンツ置換シナリオでは、第１のメディアストリームへの遷移を隠すのに役立つように、クライアントが置換期間の最後にも同様のプロセスを適用することができる。ここでは、クライアントが第１のメディアストリームの再生に戻るクライアント時間時点が切り替え時点ＴSWITCHになり、この時点は指示された置換コンテンツ（例えば、置換広告）の期間によって又は他の方法で定めることができる。次に、クライアントは、切り替え時点ＴSWITCHよりも最大予想切り替え期間ＴMAXだけ前の時点で、第２のメディアストリームから再び第１のメディアストリームに切り替えるプロセスを開始することができる。その後、クライアントは、場合によっては上述したように拡大されてフェーディングを伴う不確定期間の継続時間にわたって同様に遷移フレームを再生することができ、これによって遷移を隠すのに役立つことができる。
【００７８】
また、所望のコンテンツ切り替え時点の初期予測における不確実性を考慮するために、不確定期間及び／又はフェード期間を拡大することもできる。例えば、置換コンテンツの再生を開始するクライアント時間時点が低レートのクエリフィンガープリントに基づいて予測される場合、又はその他の問題に直面した場合、予測されるクライアント時間が完全に正確ではないこともある。これを踏まえて、クライアントは、不確定期間が通常よりも長くなるようにバイアスをかけ、従ってより長い期間にわたって遷移フレームを再生することができる。例えば、クライアントは、最大予想遷移期間がさらに長くなるようにバイアスをかけ、開始時点ＴSTARTをずらして、通常よりも前後に広がったさらに長い不確定期間を形成することもできる。これに加えて、又はこれとは別に、クライアントは、同様にさらなる不確実性を考慮するようにフェード期間３０、３２を拡大することもできる。また、クライアントは、最大予想遷移期間及び／又は最小予想遷移期間、又は関連するタイミング値を、所望の結果を達成するように調整又は設定することもできる。
【００７９】
次に、図３は、本開示に従って実行できる方法を示すフローチャートである。この方法は、メディアクライアント又はその他の再生装置などの装置が、第１のメディアストリームの再生から第２のメディアストリームの再生への遷移を容易にするために実行することができる。
【００８０】
図３に示すように、ブロック３４において、装置は、第１のメディアストリームを再生している間に、コンテンツ置換又は別の目的で第２のメディアストリームの再生を開始する目標時点を決定する。例えば、コンテンツ置換シナリオでは、この目標時点を、クライアントが第１のメディアストリームのコンテンツの代わりに第２のメディアストリームの置換コンテンツの再生を開始すべきクライアント時間時点とすることができる。装置は、数ある可能性の中でも特に、サーバ又はその他のエンティティから目標時点を指定する指令を受け取ることによって、及び／又は目標時点を決定する評価を単独で行うことによってこの目標時点を決定することができ、このプロセスは、上述したような同期ロックを設定することを含むことができる。
【００８１】
次に、ブロック３６において、装置は、第１のメディアストリームの再生から第２のメディアストリームの再生に遷移するストリーム遷移プロセスを開始する。上述したように、このストリーム遷移プロセスは、最小予想遷移期間から最大予想遷移期間までの範囲の時間を要することができる。さらに、装置は、目標時点までに第２のメディアストリームの再生を開始する準備を確実に整えるのに役立つように、決定された目標時点よりも最大予想遷移期間だけ前に戦略的に遷移プロセスを開始することができる。
【００８２】
ブロック３８において、装置は、第１のメディアストリームから第２のメディアストリームへの遷移を隠すのに役立つように、不確定期間にわたって遷移フレームシーケンスを生成して再生する。上述したように、この不確定期間は、（ｉ）遷移プロセスの開始後の最小予想切り替え期間から（ｉｉ）遷移プロセスの開始後の最大予想切り替え期間にわたる。このようにすると、装置は、たとえ不確定期間の終了前に第２のストリームの再生準備を完了した場合でも、依然として目標時点まで待ってから第２のメディアストリームの再生を開始することができ、遷移フレームはこの間にある時間を隠すのに役立つようになる。
【００８３】
さらに上述したように、方法は、不確定期間に至る第１のフェード期間にわたって装置が第１のメディアストリームから遷移フレームへのフェーディング（例えば、ディゾルブ又はモーフィング）を実行することをさらに含むことができる。同様に、方法は、不確定期間の完了時に開始する第２のフェード期間にわたって装置が遷移フレームから第２のメディアストリームへのフェーディングを実行することを含むことができる。
【００８４】
さらに、上述したように、第１及び第２のメディアストリームがビデオを含む場合、遷移フレームは、ブラックフレーム、及び／又は第１のメディアストリームの最後に再生されるフレームのコピーであるフレームを含むことができる。また、第１及び第２のメディアストリームがオーディオを含む場合、遷移フレームは無音フレームを含むことができる。その他の例も考えられる。
【００８５】
図４は、本開示に従って実行できる方法を示す別のフローチャートである。この方法も、同様にメディアクライアント又はその他の再生装置などの装置が、第１のメディアストリームの再生から第２のメディアストリームの再生への遷移を容易にするために実行することができる。さらに、この図では動作を一定の順序で示しているが、動作の順序は図示のものと異なることもできる。
【００８６】
図４に示すように、ブロック４０において、装置が、第１のメディアストリームを再生している時に、第１のメディアストリームの代わりに第２のメディアストリームの再生を開始すべき目標時点を決定する。ブロック４２において、装置は、第１のメディアストリームの再生から第２のメディアストリームの再生に遷移するストリーム遷移プロセスを開始すべき開始時点を設定する。具体的には、装置は、最大予想遷移期間を決定し、決定された目標時点よりも最大予想遷移期間だけ前になるように開始時点を設定する。次に、ブロック４４において、装置は、設定された開始時点でストリーム遷移プロセスを開始する。
【００８７】
さらに、ブロック４６において、装置は、不確定期間を決定する。具体的には、装置は、最小予想遷移期間を決定し、不確定期間が（ｉ）開始時点後の決定された最小予想遷移期間から（ｉｉ）開始時点後の決定された最大予想期間にわたるものとみなす。ブロック４８において、装置は、遷移を隠すのに役立つように、決定された不確定期間全体を通じて一連の遷移フレームを再生する。
【００８８】
この方法では、最大及び最小予想遷移期間の決定が、装置による過去のストリーム遷移のモニタリングに基づくことができ、及び／又は数ある可能性の中でも特に、これらの期間の所定の値を指定するコンフィギュレーションデータなどを読み取ることを含むことができる。
【００８９】
また、上述したように、方法は、装置が第１のメディアストリームから遷移フレームへのフェーディング、及び／又は遷移フレームから第２のメディアストリームへのフェーディングを追加することを含むことができる。遷移フレームは、ブラックフレーム、無音フレーム、及び／又は第１のメディアストリームの最後に再生されるフレームのコピーであるフレームを含むことができる。さらに、遷移は、リニア放送フィードから置換広告への、又はこの逆の遷移とすることができる。上述したように、方法は、不確定期間を延長することをさらに含むことができる。
【００９０】
最後に、図５は、上述したような動作の実行を容易にするためにこのような装置に含めることができるいくつかのコンポーネントを示すメディアクライアント例の簡略ブロック図である。上記の説明によれば、このクライアントは様々な形態を取ることができる。例えば、クライアントは、テレビ、コンピュータモニタ、又はビデオコンテンツを受け取って提示のために出力するように動作するその他の装置、及び／又はスピーカ、ヘッドフォン、又はオーディオコンテンツを受け取って提示のために出力するように動作するその他の装置とすることができる。他にも数多くの例が考えられる。
【００９１】
図５に示すように、クライアント例は、メディア入力インターフェイス５０と、ネットワーク通信インターフェイス５２と、メディア提示インターフェイス５４と、プロセッシングユニット５６と、非一時的データストレージ５８とを含み、これらの一部又は全部は共に一体化することができ、或いは図示のようにシステムバス、ネットワーク又はその他の接続機構６０によって互いに通信可能に連結することができる。
【００９２】
クライアントは、メディア入力インターフェイス５０及び／又はネットワーク通信インターフェイス５２を使用して、提示するメディアストリームを受け取ることができる。これらのインターフェイスのいずれかは、受信機、サーバ、又はその他の装置又はシステムとの通信を確立してこれらからアナログ又はデジタル形態のメディアコンテンツを受け取るための１又は２以上の有線及び／又は無線インターフェイスを含むことができる。例えば、メディア入力インターフェイスは、数ある中でも特に、ＤＶＩ、ＨＤＭＩ(登録商標)、ＶＧＡ、ＵＳＢ、ＢＬＵＥＴＯＯＴＨ(登録商標)、ＷＩＦＩなどのプロトコルに準拠する１又は２以上のインターフェイスを含むことができ、ネットワーク通信インターフェイスは、１又は２以上のサーバ及び／又はその他の装置又はシステムと相互作用するためにローカルエリア又はワイドエリアパケットベース通信を行う有線又は無線イーサネットインターフェイスを含むことができる。
【００９３】
メディア提示インターフェイス５４は、メディアコンテンツの提示を容易にする１又は２以上のコンポーネントを含むことができる。一例として、メディア提示インターフェイスは、ディスプレイ画面及び／又はスピーカなどのユーザインターフェイスと、受け取ったメディアコンテンツを処理してユーザインターフェイス上におけるコンテンツの提示を容易にするための１又は２以上のドライバ又はその他のコンポーネントとを含むことができる。
【００９４】
プロセッシングユニット５６は、１又は２以上の汎用プロセッサ（例えば、マイクロプロセッサ）及び／又は１又は２以上の専用プロセッサ（例えば、特定用途向け集積回路）を含むことができる。また、非一時的データストレージ５８は、光学、磁気又はフラッシュストレージなどの１又は２以上の揮発性及び／又は不揮発性記憶要素を含むことができる。さらに、図示のように、データストレージ５８は、本明細書で説明した様々な動作を実行するために（例えば、開示した動作をクライアントに実行させるために）プロセッシングユニット５６が実行できるプログラム命令６２を記憶することができる。
【００９５】
以上、例示的な実施形態について説明した。しかしながら、当業者であれば、本発明の実際の範囲及び趣旨から逸脱することなくこれらの実施形態に変更及び修正を行うことができると理解するであろう。
【図１】
2021534698.tif 000003
【図２】
2021534698.tif 000004
【図３】
2021534698.tif 000005
【図４】
2021534698.tif 000006
【図５】
2021534698.tif 000007
【国際調査報告】
2021534698.tif 000008
2021534698.tif 000009