JP5389449B2 - メディアエンコーダおよびデコーダの間のフィードバックおよびフレーム同期 - Google Patents

Description

メディアエンコーダとデコーダの間のフィードバックおよびフレーム同期に関する。

様々な形態のメディアコーダおよびデコーダにより、メディアをネットワーク内のポイントからポイントへ送信することができる。コーダとデコーダの協働する組み合わせを本明細書では「コーデック」と称する。さらに、「コーダ」および「エンコーダ」という用語を本明細書では同意語として使用する。

一般に、エンコーダは多数のデコーダと相互作用または協働することができる。これらのデコーダの全てを一様に構成してもしなくてもよく、またはこれらのデコーダの全ては同一の処理能力を有しても有さなくてもよい。さらに、デコーダは一般に、エンコーダに特性、特徴、または能力のような特定のデコーダの情報を与えるようには構成されない。本環境では、エンコーダは、全てのデコーダが同種の実体でない可能性があるとき、それらのデコーダが同種の実体であるかのようにデータをデコーダに送信することができる。

ネットワークは一般に損失チャネルにあたり、そのネットワーク経由で送信した若干のデータがまとめて破損、損傷、または失われることを見込んでいる。上記のデータ損失または破損から回復する様々な方式が提案されている。これらの回復方式の一部は、失われまたは損傷したデータの完全な複製を再送信することを含む。従って、これらの回復方式は不必要にネットワークの帯域幅を消費する恐れがある。

メディアエンコーダとデコーダの間のフィードバックおよびフレーム同期を可能とするシステムおよび／または方法（「ツール」）を説明する。より詳細には、エンコーダは、デコーダに送信すべきソースコンテンツに基づいてフレームをエンコードすることができる。エンコーダは、エンコーダおよびデコーダによりフレームがキャッシュされるべきかどうかを決定することができる。フレームがキャッシュされるべきである場合、エンコーダはそのフレームを１つまたは複数のキャッシュ制御ビットでエンコードすることでそのように指示することができる。デコーダはフレームをそのデコーダから受信することができ、キャッシュ制御ビットを調べてそのフレームをキャッシュすべきかどうかを決定することができる。デコーダはそのフレームをデコードすることもできる。

本要約は、選択した概念を簡潔な形で紹介するために提供される。これらの概念は以下の発明を実施するための最良の形態でさらに説明する。本要約はクレーム主題の主要な特徴または本質的な特徴を特定するようには意図しておらず、クレーム主題の範囲を決定するための支援として使用するようにも意図していない。

（概要）
以下の文書は、多くの技術やプロセスの可能なシステム（複数）および／または方法（複数）（「ツール」）を説明する。以下の議論は、メディアエンコーダとデコーダの間のフィードバックおよびフレーム同期が可能となるツールの例示的な方法を説明する。本議論はさらに、ツールが他の技術を同様に実施する方法を説明する。

本文書は便宜上、複数の部分に分類してある。限定ではなく便宜上選択した見出しでそれらの部分を紹介する。先ず、メディアエンコーダとデコーダの間のフィードバックおよびフレーム同期を実施する例示的な動作環境を説明する。次いで例示的なデータ構造を説明し、その後例示的なデータフローを説明する。最後に例示的なプロセスフローを説明する。

本明細書では、「パケット」および「フレーム」という用語を例示や議論の便宜上
使用する。さらに便宜のため、全てのフレームが１つのパケットのペイロードに適合できるものとし、従って所与のフレームと次のフレームの区別を議論するときにパケット数がフレーム数と等しいものと仮定し得るものとする。

（動作環境）
ツールを詳細に説明する前に、以下の例示的な動作環境の議論は、ツールの様々な態様を使用し得る１つの方法の理解において読み手を助けるために提供される。以下で説明する環境は１つの例を構成するに過ぎず、ツールの適用を任意のある特定の動作環境に限定するようには意図していない。クレーム主題の精神および範囲から逸脱することなく、他の環境が使用され得る。

図１は、上記の動作環境の１つを一般的に１００で示す。動作環境１００は、１つまたは複数のプロセッサ（複数）１０４ａとコンピュータ読取可能媒体１０６ａとを有するワークステーション１０２ａを備えることができる。ワークステーション１０２ａは、携帯電話、デスクトップコンピュータ、携帯情報端末、サーバ、等のようなコンピューティング装置を備えることができる。プロセッサ１０４ａは、コンピュータ読取可能媒体１０６ａにアクセスおよび／または実行するように構成され得る。コンピュータ読取可能媒体１０６ａは、モジュール、プログラム、またはネットワーク可能な実体と相互作用可能な他の実体として実装し得るエンコーダ１０８を備えたり或いはエンコーダ１０８に対するアクセスを有したりできる。

エンコーダ１０８は、ソースコンテンツ１１０を複数の対応フレーム１１２にエンコードするよう動作することができる。ソースコンテンツ１１０は、スピーカまたは他のパフォーマ（ｐｅｒｆｏｍｅｒ）を特徴とするライブプレゼンテーションなどのいくつかの異なる形態を想定できる。ソースコンテンツ１１０はビデオおよび／またはオーディオ会議でもよい。最後に、ソースコンテンツ１１０は、オーディオまたはビデオメディアなどの既存または記録済みのメディアでもよい。

動作環境１００は、ネットワーク１１４と関連するサーバ（複数）１１６とを備えることもできる。ネットワーク１１４は、ワークステーション１０２とサーバ（複数）１１６との間の通信を可能とし、インターネットまたは企業イントラネットのようなグローバルまたはローカルの有線または無線ネットワークを備えることができる。エンコーダ１０８は、ネットワーク１１４上の送信に適したプロトコルを用いてソースコンテンツ１１０をフレーム１１２にエンコードするよう動作し得る。

サーバ（複数）１１６は単一のサーバまたはサーバファームなどの複数のサーバを備えることができるが、サーバ（複数）１１６は、他の実体と通信可能な、又は（例えば、ロードバランシングのために）個々のサーバを管理可能な、追加のサーバまたは非サーバ実体を備えることもできる。サーバ（複数）１１６は、例えばワークステーション１０２からの要求をサービスするのに直列または並列に動作する３つの別々のサーバ１１６ａ、１１６ｂ、および１１６ｃで示されている。

ネットワーク１１４は、ワークステーション１０２ａからのフレーム１１２を少なくとも１つの追加のワークステーション１０２ｂに送信するよう動作することができる。ネットワーク１１４は、フレーム１１２の全てを完全にワークステーション１０２ａからワークステーション１０２ｂに送信しなくてもよいことが理解される。従って、図１内の参照番号１１２はワークステーション１０２ａから出ていくフレームを表し、参照番号１１８はネットワーク１１４から現れてワークステーション１０２ｂに与えられるフレームを表す。フレーム１１８と比較して、幾つかのフレーム１１２がネットワーク１１４を通して送信中に失われ、歪み、または破損する可能性がある。従って、フレーム１１２の一部が失われる場合、受信したフレーム１１８を送信したフレーム１１２の部分集合（subset）と見ることができる。また、フレーム１１２の一部が破損する場合、受信したフレーム１１８を、破損した状態の送信したフレーム１１２と見ることができる。

ワークステーション１０２ｂの詳細に移ると、上述のワークステーション１０２ａと同様に実装し得る。従って、ワークステーション１０２ｂは、プロセッサ（複数）１０４ｂおよびコンピュータ読取可能媒体１０６ｂを含んでもよい。コンピュータ読取可能媒体１０６ｂは、デコーダ１２０を備えるかまたはデコーダ１２０に対するアクセスを有することができる。

デコーダ１２０は、ネットワーク１１４経由でワークステーション１０２ａから受け取るようにフレーム１１８を受信しおよびデコードするよう動作することができる。デコーダ１２０は、エンコーダ１０８が以前にフレーム１１２のエンコードに使用したものと同じプロトコルを使用してフレーム１１８をデコードすることになる。フレーム１１２に対してフレーム１１８が破損、損傷、または失われていないとデコーダ１２０が決定する場合、デコーダはこれらのフレーム１１８を、デコード済みコンテンツ１２２にデコードできる。

デコード済みコンテンツ１２２は、ワークステーション１０２ｂ上で再生したソースコンテンツ１１０を表す。例えば、ソースコンテンツ１１０がライブプレゼンテーションである場合、デコード済みコンテンツ１２２はワークステーション１０２ｂ経由で表示したプレゼンテーションを表すことができる。ソースコンテンツ１１０が口頭の会議関連のオーディオまたはビデオストリームである場合、デコード済みコンテンツ１２２は、別の会議参加者によって視られまたは聴かれたオーディオまたはビデオストリームでもよい。別の例として、ソースコンテンツ１１０が既存または記録済みのメディアである場合、デコード済みコンテンツ１２２はワークステーション１０２ｂ経由で表示したメディアを表すことができる。

上述したものを提供することにおいて、動作環境１００は単方向の性質に限定されないことが理解される。寧ろ、ワークステーション１０２ａは幾つかの時点で特定のソースコンテンツ１１０を送信することができ、一方でワークステーション１０２ｂは他の時点で他のソースコンテンツ１１０を送信することができる。従って、本明細書の図１および他の図面に示されたデータフローは例示に過ぎず、限定ではない。

デコーダ１２０の処理に戻ると、フレーム１１８の一部がネットワーク１１４を介した送信中に破損または損傷したとデコーダ１２０が決定する場合、またはフレーム１１２の一部が失われワークステーション１０２ｂに決して到達しなかったとデコーダ１２０が決定する場合、デコーダ１２０はそれに従ってエンコーダ１０８に報告することができる。より詳細には、デコーダ１２０はフィードバックチャネル１２４を使用してエンコーダ１０８に報告することができる。フィードバックチャネル１２４は、ネットワーク１１４を使用して少なくとも部分的に実行することができるが、フィードバックチャネル１２４経由でデータをエンコードおよび／または送信するために使用するプロトコルは、フレーム１１２および１１８をエンコードおよび／または送信するために使用するプロトコルと同一であっても同一でなくともよい。ネットワーク１１４経由でフィードバックチャネル１２４を通して移動するデータが参照番号１２４ａおよび１２４ｂで表される。ネットワーク内のエラーまたは他の問題のため、フレーム１１２がフレーム１１８と異なり得るのと同じ理由で、データ１２４ａおよび１２４ｂは幾分異なり得る。

失われ、損傷し、または破損したフレーム１１２または１１８のレポートを受信すると、エンコーダ１０８は補正したまたは置き換えたフレーム１１２をデコーダ１２０に送信することができる。損傷したフレームを報告し、補正したまたは置き換えたフレーム１１２を送信するこの処理は、ワークステーション１０２ｂ上にデコード済みコンテンツ１２２を生成するために、デコーダ１２０がフレーム１１８のデコードに適切な情報を有するまで繰り返すことができると理解される。

フレーム損失の報告に使用されるフィードバックチャネル１２４の追加の態様が以下でさらに詳細に説明される。しかしながら、フィードバックチャネル１２４は、デコーダ１２０がそれ自身に関する情報、その構成、または他の関連パラメータを通信しエンコーダ１０８に戻すことも可能にし得る。デコーダ１２０に関するこの情報が与えられると、エンコーダ１０８はそれに応じてそのエンコーディング処理を調整または最適化することができる。デコーダ１２０に関する情報の報告に用いるフィードバックチャネル１２４のこれらの態様も以下でさらに説明される。前述の説明を踏まえて、フィードバックチャネル１２４はデコーダ（複数）１２０に帯域外チャネルを与えてエンコーダ１０８と通信し得る。

明確さおよび読み易さのため図１では１つのワークステーション１０２ｂおよび関連するデコーダ１２０のみが示されており、それらは動作環境１００の可能な実装を限定するものではないことが理解される。特に、任意の数の異なるワークステーション１０２ｂおよび対応するデコーダ１２０が含まれてもよく、異なるワークステーション１０２ｂおよびデコーダ１２０は異なる構成、特徴、容量、能力、または他の特性を有することができることが指摘される。例えば、異なるワークステーション１０２ｂは、異なる色深度、画素解像度、ディスプレイサイズ、もしくはソースコンテンツ１１０および／またはデコード済みコンテンツ１２２を処理する他の態様をサポートすることができる。各ワークステーション１０２ｂおよび／またはデコーダ１２０はそれぞれのフィードバックチャネル１２４を有し得ることがさらに理解される。このフィードバックチャネル１２４を使用して、ワークステーション１０２ｂおよび／またはデコーダ１２０は、それらのローカル環境に密接に関わる特定のローカル情報をエンコーダ１０８に戻すことを提供できる。

（データ構造）
本明細書で説明しおよび例示したツールは、データ構造をそのツールの実装および／または動作の一部として利用して、メディアエンコーダとデコーダの間のフィードバックおよびフレーム同期を行うことができる。上記データ構造の例がここで説明される。

図２はデータ構造２００を示すもので、データ構造２００の少なくとも一部は、図１に示されたフレーム１１２および／または１１８のそれぞれのインスタンスの実装に適している可能性がある。例えばエンコーダ１０８およびデコーダ１２０がリアルタイム転送プロトコル（ＲＴＰ）を実装することのみを仮定して、データ構造２００は、所与のフレーム１１２および／または１１８に対してＲＴＰ標準ヘッダに関するフィールド２０５と、フレーム１１２および／または１１８のペイロードと考えられるデータを含むフィールド２１０とを含むことができる。さらに、データ構造２００は追加のヘッダデータに対するフィールド２１５を含むことができる。フィールド２１５に含まれるデータは、エンコーダ１０８およびデコーダ１２０により使用される基本的なプロトコルに対する拡張と考えられ得る。図２に示す例では、プロトコルはＲＴＰであることができるが、他のプロトコルを等しく適用可能であることもまた理解される。

フィールド２１５のより詳細に移ると、図２は特定のフレーム１１２および／または１１８に対するフィールド２１５に含まれ得るデータの幾つかの例を示す。サブフィールド２２０は１つまたは複数のキャッシュ制御ビットを含むことができる。これらのキャッシュ制御ビット２２０は、エンコーダ１０８が、デコーダ１２０によって特定のフレーム１１２および／または１１８のキャッシングを制御および／または管理するのを可能にできる。これらのビット２２０は、エンコーダ１０８とデコーダ１２０の幾つかとの間のフレーム回復および同期動作をサポートすることができる。このフレームキャッシング動作が以下でさらに詳細に説明される。

サブフィールド２２２は、所与のフレーム１１２および／または１１８に対して、それがどのようなタイプのフレームであるかを示すことができる。図２には３つのタイプのフレームを示してあるが、他のタイプのフレームが実装されてもよく、実装したフレームを本明細書で述べたものと異なる名前付けまたはラベル付けできることも理解される。

サブフィールド２２２に示すように、Ｉフレームは、例えばオーディオまたはビデオのようなコンテンツの完全な自己完結型フレームを表す。Ｉフレームは「独立」しており、他の以前のまたは後続のフレームを参照することなくデコーダ１２０によりデコードされおよび再生され得る。

Ｐフレームは、オーディオまたはビデオの現在状態と以前のＩフレームとの間の差分を表す。従って、Ｐフレームは以前のＩフレームを参照すると言うことができる。Ｐフレームはこの以前のＩフレームに対する差分のみを表すデータを含むので、Ｐフレームは一般にＩフレームより非常に小さい。ネットワーク１１４に渡る帯域幅を節約するため、Ｐフレームを可能な限り利用することが適切であろう。ソースコンテンツ１１０が一定の時間に渡って比較的少さな動作を示すとき、エンコーダ１０８は一連のＰフレームを使用することができる。なぜならばそのような状況下では、後続のフレームにおける差分は一般的に相対的に小さく、Ｐフレームにより容易に表されるからである。しかしながら、ソースコンテンツ１１０が一定の時間に渡って比較的大きな動作を示すか、もしくはシーンまたはコンテクストの大幅な変化を示すとき、エンコーダ１０８は新規のシーンまたはコンテクストを設定するために１つまたは複数のＩフレームを使用することができる。また、ワークステーション１０２ｂおよび／またはデコーダ１２０によって生じた損失率が、ワークステーション１０２ａおよび／またはエンコーダ１０８に報告され得る。次いで、エンコーダ１０８はデコーダ１２０によって報告された損失率を、ＩフレームまたはＰフレームをデコーダ１２０に送信するかどうかの決定において考慮することができる。さらに、報告された損失率は、フレーム速度、ビット速度、品質、およびスーパーＰフレーム（Ｓｕｐｅｒ−Ｐ ｆｒａｍｅ）を送信するかどうか、の制御における１つの因子となり得る。

サブフィールド２２２は追加のタイプのフレーム１１２および／または１１８をサポートすることもできる。そのフレームを本明細書では限定ではなく便宜上、スーパーＰフレームと称する。スーパーＰフレームはそれがコンテンツ内の変化をそのコンテンツの以前の状態に対して定義する点でＰフレームと似ている。しかしながら、以前のフレームを参照する代わりに、スーパーＰフレームはデコーダ１２０上でローカルに維持されるキャッシュの内容を参照する。このキャッシング動作が以下でさらに詳細に説明される。

サブフィールド２２４は、所与のフレーム１１２および／または１１８に対する索引または他のタイプの一意な識別子を含むことができる。例えば、サブフィールド２２４の内容は、フレームまたはパケットに対するシーケンス番号、一意なタイムスタンプ、所与のフレーム１１２および／または１１８のソースコンテンツ１１０のコンテクストにおけるオフセットまたは位置、所与のフレーム１１２および／または１１８のソースコンテンツ１１０の先頭に対する変位、等の形態を取ることができる。

ワークステーション１０２ａでソースコンテンツ１１０をフレーム１１２にエンコードするとき、どのような形態であれ、サブフィールド２２４の内容をエンコーダ１０８により埋めることができる。ワークステーション１０２ｂで、デコーダ１２０は、複数のフレーム１１８をデコード済みコンテンツ１２２にデコードし組み立てるとき、所与のフレーム１１８に対するサブフィールド２２４の内容を参照することができる。より詳細には、サブフィールド２２４の内容は、デコーダ１２０が、デコード済みコンテンツ１２２を提示するときにフレーム１１８を適切な順序に組み立てることを可能にすることができる。さらに、デコーダ１２０は、エンコーダ１０８により送信した１つまたは複数のフレーム１１２がネットワーク１１４を通してワークステーション１０２ｂに送信する間に失われたかどうかを決定するために、サブフィールド２２４の内容を少なくとも部分的に使用することができる。

前述したことの例として、デコーダ１２０はＡ、Ｂ、およびＤなどの識別子２２４を有する一連の所与のフレーム１１８を受信してもよい。しかしながら、デコーダ１２０はこれら３つのフレーム１１８がＡ、Ｂ、およびＣとして識別子２２４を有すると期待する恐れがある。デコーダ１２０が幾分かの時間フレームＣを受信しないと、デコーダ１２０は、期待したフレームＣに対応するフレーム１１２が決して到達することはなく、ネットワーク１１４内で失われたと結論付けるかもしれない。それゆえに、デコーダ１２０はデコーダ１２０に対し、パケットＣが失われたことを例えばフィードバックチャネル１２４を通して報告してもよい。

サブフィールド２２６は、特定のデコーダ１２０の特性または構成に基づいてエンコーダ１０８が実施する色空間変換に関するデータを含むことができる。上記図１の議論から、デコーダ１２０の特定のインスタンスは、それらのローカル色表示能力または特徴に関連する情報をエンコーダ１０８に対して、例えばフィードバックチャネル１２４経由で送信し戻すことができることを思い出さなければならない。特定のデコーダ１２０からのこのフィードバックに応じて、エンコーダ１０８は、その特定のデコーダ１２０の各々に送信されたフレーム１１２を具体的に調整することができる。所与のデコーダ１２０の代わりにエンコーダ１０８によって実施された特定の色変換に関連する任意のデータは、サブフィールド２２６に格納され得る。例えば、ソースコンテンツ１１０は、２５６色の例示的な範囲で取り込まれ、エンコーダ１０８に提示され得る。しかしながら、所与のデコーダ１２０が１６色をサポートし表示できるに過ぎない場合、２５６色をサポートするフレーム１１２をこの所与のデコーダ１２０に送信することは有用ではないであろう。従って、エンコーダ１０８はデコーダ１２０に対し、サブフィールド２２６に含まれるデータを通して、フレーム１１２内で表されたものをデコーダ１２０によってサポートされる色に変換する方法を指示してもよい。前述したことに加え、またはその代わりとして、エンコーダ１０８はサブフィールド２２６内のデータを通して、エンコーダ１０８がフレーム１１２内の色をどのように既に変換したかをデコーダ１２０のために示してもよい。

サブフィールド２２８は、特定のデコーダ１２０の代わりにエンコーダ１０８が実施した任意の画素解像度変換に関連するデータを含むことができる。上記図１の議論から、デコーダ１２０の特定のインスタンスはそれらの画素解像度などのデータを例えばフィードバックチャネル１２４経由でエンコーダ１０８に送信できることを思い出さなければならない。色深度に関するサブフィールド２２６の上述の議論を参照すると、サブフィールド２２８は、画素解像度に関して同様な処理を可能にできる。例えば、ソースコンテンツ１１０は、相対的に高い画素密度で取り込まれ、エンコーダ１０８に提示され得る。しかしながら、１つまたは複数のデコーダ１２０がこの高い画素密度をサポートしない可能性があり、異なるデコーダ１２０が異なる画素密度をサポートする可能性がある。従って、エンコーダ１０８は、異なるデコーダ１２０に送信した異なるフレーム１１２の画素密度を、その異なるデコーダ１２０の能力に応じて最適化してもよい。従って、サブフィールド２２８は、エンコーダ１０８によって行われた画素解像度における任意の変換に関連する任意の情報、またはフレーム１１８の処理においてデコーダ１２０が行うべき任意の変換に関連する任意の情報を含むことができる。

フィールド２０５−２１５およびサブフィールド２２０−２２８の前述の例を説明によって、データ構造２００の様々な実装は１つまたは複数のこれらの例示的なフィールド２０５−２１５またはサブフィールド２２０−２２８を含むことができ、または図２に示したもの以外の追加のデータ、フィールド、またはサブフィールドを含むことができることが理解される。さらに、データ構造２００のフィールドまたはサブフィールドのレイアウト、名前、および構成は例に過ぎず、例示および説明の便宜を図るためにのみ選択したものであり、データ構造２００の可能な実装を限定しない。さらに、データ構造２００の所与のインスタンスを特定のフレーム１１２に関連付けることができるが、データ構造２００の各インスタンスは、図２に示すように各フィールドおよび／またはサブフィールドに埋めておく必要はないことが理解される。

図３はデータ構造３００を示しており、データ構造３００の少なくとも一部は図１に示すフィードバックチャネル１２４のそれぞれのインスタンスの実装に適し得る。より詳細には、デコーダ１２０のそれぞれのインスタンスからエンコーダ１０８へのデータ送信を、少なくとも部分的に、データ構造３００を使用して容易にすることができる。

データ構造３００のより詳細に移ると、フィールド３０５は、デコーダ１２０の幾つかで生じたローカルフレームまたはパケットの損失率を報告するデータを含むことができる。この損失率は、例えば特定のデコーダ１２０で生じた時間単位当りの損失フレーム数として表現することができる。この情報が与えられると、エンコーダ１０８はＩフレームまたはＰフレームのデコーダ１２０への送信頻度を選択することができる。また、この情報は、特定のフレーム１１２／１１８をキャッシュするようデコーダ１２０に命令または指示する時期および／または頻度を、エンコーダ１０８が決定するのを可能にできる。これらのキャッシング動作は、図４−６に関連してさらに以下で議論される。

フィールド３１０は特定のフレーム１１２／１１８の損失を報告するデータを含むことができる。フレーム損失の報告において、デコーダ１２０は、図２に示すサブフィールド２２４に関して前に議論したようなデータを参照することができる。サブフィールド２２４は、特定のフレーム１１２／１１８に対する識別情報を含むことができることを思い出さなければならない。例えば、デコーダ１２０は１つまたは複数のフレーム１１２が失われていると疑う場合、デコーダ１２０は実際に受信した一連のフレーム１１８を報告することができ、その結果、エンコーダ１０８はどのフレーム１１２が失われたかを決定することができる。別の例では、デコーダ１２０は失われたと疑われるフレーム１１２に対する識別情報を推測または決定することができる。

フィールド３１５は、特定のデコーダ１２０がサポートするローカル画素解像度を表すデータを含むことができる。デコーダ１２０が報告したこのデータ３１５に応じて、エンコーダ１０８は、デコーダ１２０に送信したフレーム１１２／１１８の画素解像度を変換することができ、デコーダ１２０に対してフレーム１１２／１１８の画素解像度の変換方法を指示することができ、または他の関連処理を実施することができる。前述したようなことは、図２に示すサブフィールド２２８と関連して実施され得る。

フィールド３２０は、特定のデコーダ１２０がサポートするローカル色深度を表すデータを含むことができる。デコーダ１２０が報告したこのデータ３２０に応じて、エンコーダ１０８はデコーダ１２０に送信したフレーム１１２／１１８の色深度を変換することができ、デコーダ１２０に対してフレーム１１２／１１８の色深度の変換方法を指示することができ、または他の関連処理を実施することができる。前述したようなことを、図２に示すサブフィールド２２６と関連して実施することができる。

フィールド３０５−３２０の前述の例の説明によって、データ構造３００の様々な実装は１つまたは複数のこれらの例示的なフィールド３０５−３２０を含むことができ、もしくは図３に示したもの以外の追加のデータ、フィールド、またはサブフィールドを含むことができることが理解される。さらに、データ構造３００のフィールドのレイアウト、名前、および構成は例に過ぎず、例示および説明の便宜上としてのみ選択したものであり、データ構造３００の可能な実装を限定しない。さらに、データ構造３００の所与のインスタンスは、デコーダ１２０からエンコーダ１０８に送信したデータの特定のインスタンスに関連付けることができることが理解される。しかしながら、データ構造３００の各インスタンスは図３に示すように各フィールドに埋めておく必要はない。

（データフロー）
本明細書で説明したツールは、メディアエンコーダとデコーダの間のフィードバックおよびフレーム同期の実施に適したデータフローを実装することができる。例示的なデータフローを別の動作環境と関連して説明する。

図４は、フレーム１１８を受信し、新規フレーム１１８を以前のディスプレイと統合して最新のディスプレイを生成し、フレーム１１８をキャッシュし、および新規フレーム１１８とキャッシュの内容とを統合して最新のディスプレイを生成するための動作環境４００を示す。動作環境４００は、少なくとも部分的に、ワークステーション１０２ｂおよび／またはデコーダ１２０により実装され得るが、動作環境４００の態様は、同様に他の構成要素またはツールによっても実装され得る。

時刻（Ｔ_１）でフレーム１１８ａが受信されると仮定する。図２に関連して上で議論したように、フレーム１１８は、データ構造２００のそれぞれのインスタンスと関連付けることができることを思い出さなければならない。さらに、フレーム１１８ａに対するデータ構造２００のフィールド２２２は、フレーム１１８ａがＩフレームであることを示すと仮定する。フレーム１１８ａはＩフレームであるので、フレーム１１８ａは、例えばワークステーション１０２ｂに関連付けたディスプレイ４０２上に直接提示され得る。便宜上、Ｉフレーム１１８ａを提示するときに有効になるディスプレイ４０２を図４ではディスプレイ４０２ａとして示されている。

図２の議論から、フレーム１１２／１１８に対するデータ構造２００は、キャッシュ制御ビット２２０を含み得ることが思い出さなければならない。動作環境４００を説明する目的で、データ構造２００は２つのキャッシュ制御ビット２２０を含むと仮定する。第１のキャッシュ制御ビットは「Ｃａｃｈｅ」とラベル付けされ、少なくとも第２のキャッシュ制御ビットは「Ｕｓｅ Ｃａｃｈｅ」とラベル付けされることができる。これらのビットのいずれかまたは両方は、所与のフレーム１１８に対して設定されまたはアクティブにされ得る。

先ず「Ｃａｃｈｅ」ビットについて述べる。このビットが所与のフレーム１１２／１１８に対して設定されるとき、このビットはデコーダ１２０にフレーム１１２／１１８、および／またはそのフレーム１１２／１１８から生ずるディスプレイを、ワークステーション１０２ｂおよび／またはデコーダ１２０がローカルに維持するキャッシュ４０４に格納するよう命令する。従って、図４に示す例では、ブロック４０６で示すように、Ｉフレーム１１８ａは設定されまたはアクティブな「Ｃａｃｈｅ」ビットを有すると仮定している。従って、Ｉフレーム１１８ａはディスプレイ４０２ａとして提示され、キャッシュ４０４に格納されるであろう。

動作環境４００の幾つかの実装は、デフォルトでＩフレーム１１２／１１８の全てのインスタンスをキャッシュすることができる。動作環境４００の他の実装は、それらの「Ｃａｃｈｅ」ビットが設定されまたはアクティブなＩフレーム１１２／１１８のみをキャッシュしてもよい。

時刻（Ｔ_２）でフレーム１１８ｂが到達し、そのフレームタイプ２２２はそれがＰフレームであることを示すと仮定する。Ｐフレームは、ソースコンテンツ１１０の現在状態と幾つかの以前の参照フレームとの間の差分を表すことを思い出さなければならない。従って、マージブロック４０８ａで表すように、フレーム１１８ｂの内容が以前のディスプレイ４０２ａと統合される。マージ４０８ａは、最新のディスプレイ４０２ｂをもたらす。

Ｐフレーム１１８ｂの処理を説明によって、一般的にＰフレーム１１８はその「Ｃａｃｈｅ」ビットを設定しまたはアクティブにできることに留意されたい。上記の場合において、動作環境４００の幾つかの実装では、Ｐフレーム１１８自体の内容はキャッシュ４０４に格納され得る。他の実装では、Ｐフレーム（例えば、フレーム１１８ｂ）の統合から生ずるディスプレイ（例えば、ディスプレイ４０２ｂ）がキャッシュされ得る。

時刻（Ｔ_３）でフレーム１１８ｃが到達し、そのフレームタイプ２２２はそれがＰフレームであることを示すと仮定する。この場合において、マージブロック４０８ｂで表すように、フレーム１１８ｃの内容が以前のディスプレイ４０２ｂと統合される。マージ４０８ｂは、最新のディスプレイ４０２ｃをもたらす。しかしながら前述したことは、フレーム１１８ｃが実際に動作環境４００に到達することを仮定している。フレーム１１８ｃが動作環境４００で到達できなかった場合、最新のディスプレイ４０２ｃは存在しないであろう。さらに、動作環境４００がフレーム損失を検出する時には、以前のディスプレイ４０２ｂは有効期限切れであるか、または無効となっているかもしれない。この場合、エンコーダ１０８はフレーム損失の通知をもらうことができる。例えば、図３のブロック３１０および関連する議論を参照のこと。

フレーム損失レポート３１０に応答して、エンコーダ１０８は置換Ｐフレーム１１８ｄを送信することができる。動作環境４００は、この置換Ｐフレーム１１８ｄを時刻（Ｔ_４）で受信すると仮定する。ブロック４１０で示すように、置換Ｐフレーム１１８ｄに対するキャッシュ制御ビット２２０はその「Ｕｓｅ Ｃａｃｈｅ」ビットを設定しまたはアクティブにすることができる。「Ｕｓｅ Ｃａｃｈｅ」ビットは、動作環境４００に、現在のＰフレーム１１８ｄと以前のディスプレイではなくキャッシュ４０４の内容とを統合するよう命令する。このキャッシュからの統合は、マージブロック４０８ｃで一般的に表される。

この置換Ｐフレーム１１８ｄは、以前のＩフレームではなくキャッシュした参照フレームに対してエンコードされるので、このＰフレーム１１８ｄを本明細書では上述のようにスーパーＰフレームと称する。エンコーダ１０８はキャッシュした参照に基づいてスーパーＰフレーム１１８ｄをエンコードするので、スーパーＰフレーム１１８ｄは置換Ｉフレーム１１８より非常に小さくなる。従って、フレーム損失を補うためのスーパーＰフレーム１１８ｄの送信は、置換Ｉフレーム１１８を送信するよりも少ないネットワーク帯域幅を消費する。

幾つかの実装では、破損したフレームがデコーダ１２０に到達する次のＩフレーム１１８ｅと十分に近い場合、エンコーダ１０８はスーパーＰフレーム１１８ｄを送信しなくともよい。上記の実装では、デコーダ１２０は次のＩフレーム１１８ｅを待ってもよい。デコーダ１２０は、この処理を行うために破損フレームが次のＩフレーム１１８ｅとどの程度近くなければならないかに関連して指定する１つまたは複数の設定で構成され得る。

スーパーＰフレーム１１８ｄがキャッシュ４０４の内容と統合された後、ディスプレイ４０２ｄが生ずる。図４はさらに、時刻（Ｔ_５）で新規のＩフレーム１１８ｅが到達し、新規のディスプレイ４０２ｅが生ずることを示す。

図４では、例示および説明の便宜上としてのみ１つのキャッシュ４０４を示してあることに留意されたい。複数の参照フレーム１１２／１１８がエンコーダ１０８および／またはデコーダ１２０により格納および保持できるように、追加のキャッシュ４０４がエンコーダ１０８および／またはデコーダ１２０により与えられ得る。これらの複数の参照フレーム１１２／１１８は、１つまたは複数のキャッシュしたフレーム１１２／１１８が破損しまたは失われた可能性のある場合に役立ち得る。複数のキャッシュ４０４が実装される場合、所与の置換フレーム１１２／１１８をエンコードするためにどのキャッシュ４０４を使用したかを要求または示すのに適すように追加のキャッシュ制御ビット（例えば、図２のキャッシュ制御ビット２２０）が実装され得る。

さらにキャッシュ制御ビット２２０は、置換フレーム１１２／１１８のキャッシングおよび関連する同期の扱い方についてエンコーダ１０８がデコーダ１２０に指示できるための手段を提供することに留意されたい。最後に、エンコーダ１０８およびデコーダ１２０でキャッシュした参照フレーム、およびそこからエンコードした置換フレーム１１２／１１８は、エンコーダ１０８およびデコーダ１２０の処理の同期をとるための手段を提供する。

（プロセスフロー）
本明細書で説明したツールは、メディアエンコーダとデコーダの間のフィードバックおよびフレーム同期を実施する様々なプロセスフローを実行することができる。上記プロセスフローの例がここで説明される。

図５に示すプロセスフロー５００は、フレームのエンコードやパケット損失レポートへの応答が実施され得る。プロセスフロー５００は、ここではエンコーダ１０８に関連して説明される。しかしながら、プロセスフロー５００は、本明細書の精神および範囲から逸脱することなくエンコーダ１０８以外の装置または構成要素上で実行できることが理解される。

ブロック５０２はソースコンテンツ１１０からの１つまたは複数のフレームをエンコードする。ブロック５０４は後に起こりうる参照のためカレントフレーム１１２をキャッシュすべきかどうかを判定する。フレーム１１２がキャッシュされるべきである場合、ブロック５０６は「Ｃａｃｈｅ」ビットをカレントフレーム１１２に対して設定する。「Ｃａｃｈｅ」ビットは、図２に示すキャッシュ制御ビット２２０の一部として実装できることを思い出さなければならない。ブロック５０８はカレントフレーム１１２を後の参照のためキャッシュする。例えば、カレントフレーム１１２は、エンコーダ１０８によりキャッシュされ得る。ブロック５１０はカレントフレーム１１２をデコーダ１２０に送信する。例えばデコーダ１２０でのフレーム１１２の例示的な処理は、図６に関連して以下で説明される。

ブロック５０４に戻ると、カレントフレーム１１２がキャッシュされるべきでない場合、ブロック５１２はこのフレーム１１２に対して「Ｃａｃｈｅ」ビットをクリアする。幾つかのインスタンスでは、フレーム１１２がインスタンス化されるときに「Ｃａｃｈｅ」ビットは設定またはクリア状態に初期化され得る。上記の場合、「Ｃａｃｈｅ」ビットの状態をその初期化状態から変更する必要がないならば、ブロック５１２または５０６を実施しなくともよい。

ブロック５１２の後、プロセスフロー５００は上述したようなブロック５１０に進む。ブロック５１０を実施した後、プロセスフロー５００は、ソースコンテンツ１１０がエンコードされる次のフレーム１１２を処理するためにブロック５０２に戻ることができる。プロセスフロー５００は、ソースコンテンツ１１０を適切なフレーム１１２にエンコードするのに適するようにブロック５０２−５１２を通してループしてもよいことが理解される。

ブロック５０２−５１２の処理中の任意の時点で、ブロック５１４はフレーム損失レポート３１０を受信することができる。ブロック５１４は、プロセスフロー５００内の任意の点で起こり得る。プロセスフロー５００は、ブロック５０２−５１２における任意の点でフレーム損失レポート３１０の受信に対しテストしまたはそれに応答してもよい。さらに、プロセスフロー５００は、割り込みとしてブロック５１４を実行しても、ブロック５０２−５１２内の幾つかの点から分岐してその割り込みを処理しても、（以下で説明する）ブロック５１６−５２２を割り込み処理ルーチンとして実施しても、および割り込みを受信したブロック５０２−５１２内の点に戻ってもよい。例示の便宜上、図５は、プロセスフロー５００がブロック５０２−５１２内のどこにいるかに関わらずフレーム損失レポート３１０を受信したときにブロック５１４に分岐するプロセスフロー５００を示している。

ブロック５１６は、以前にブロック５０８でキャッシュされたフレームを参照する。ブロック５１８は、そのキャッシュしたフレームに対して、またはそのキャッシュしたフレームを参照して、新規のＰフレームをエンコードする。ブロック５２０は、新規のＰフレームの「Ｕｓｅ Ｃａｃｈｅ」ビットを、それがまだ設定されていない場合に設定する。図２で示し議論したキャッシュ制御ビット２２０は、「Ｕｓｅ Ｃａｃｈｅ」ビットを含んでもよく、この「Ｕｓｅ Ｃａｃｈｅ」ビットは、カレントディスプレイ４０２を更新するとき、例えばデコーダ１２０に命令して、カレントディスプレイ４０２ではなくキャッシュ４０４の内容を参照することを思い出さなければならない。この新規のＰフレームは、本明細書では便宜上としてのみスーパーＰフレームと称する。ブロック５１４で報告したフレームの損失をデコーダ１２０が補うことができるように、ブロック５２２はスーパーＰフレームをデコーダ１２０に送信する。

図６は、例えばデコーダ１２０が受信するフレームを処理するプロセスフロー６００を示す。プロセスフロー６００は本明細書では、デコーダ１２０やエンコーダ１０８などのツールと関連して説明されるが、プロセスフロー６００の他の実装を、本明細書の説明の精神および範囲から逸脱することなく他のツールで実装することもできる。

ブロック６０２は、例えば図５に示すブロック５１０で送信したフレーム１１８を受信する。ブロック６０４は、受信したフレーム１１８が破損しているかどうか、または異なるフレーム１１８を予測したかどうかをテストする。フレームの破損に関して、ブロック６０４は例えば、デコーダ１２０および／またはエンコーダ１０８が実装するチェックサムまたは他のエラー検出訂正方式を判定することで、破損をテストできる。図２で上述したように、フレーム損失に関して、フレーム１１８はデータ構造２００のそれぞれのインスタンスと関連付けられ得ることを思い出さなければならない。データ構造２００は、フレーム１１８を順序付けたり或いは一意に識別するフィールド２２４を含むことができる。例えばこのフィールド２２４を使用して、ブロック６０４は、カレントフレーム１１８が以前のフレーム１１８の後に来ることが予測されるかどうかをテストできる。そうでなければ、予測した後続フレーム１１８が失われている恐れがある。

カレントフレーム１１８が破損しているかまたは予測したものでない場合、ブロック６０６はその失われまたは破損したフレームを報告する。ブロック６０６から発行したレポートは、図５に示すブロック５１４で受信したレポートや図３に示すフレーム損失レポート３１０に相当し得る。

カレントフレーム１１８が破損しておらず、かつ予測した後続フレームである場合、ブロック６０８、６１０、および６１２はフレーム１１８のフレームタイプが何かをテストすることができる。データ構造２００はフレームタイプを示すサブフィールド２２２を含み得ることを思い出さなければならない。ブロック６０８はフレーム１１８がＩフレームであるかどうかをテストし、ブロック６１０はフレーム１１８がＰフレームであるかどうかをテストし、ブロック６１２はフレーム１１８がスーパーＰフレームであるかどうかをテストする。

ブロック６０８に戻ると、フレーム１１８がＩフレームである場合、ブロック６１４は、カレントディスプレイまたは任意の他のフレーム１１８を参照することなくフレーム１１８を直接表示することができる。ブロック６１０で、フレーム１１８がＰフレームである場合、ブロック６１６はカレントディスプレイを、それをフレーム１１８と統合することで更新する。ブロック６１４は次いで、その最新のフレームを表示する。ブロック６１２で、フレーム１１８がスーパーＰフレームである場合、ブロック６１８はディスプレイを、それを図４に示すキャッシュ４０４などのキャッシュの内容と統合することで更新する。スーパーＰフレームは、設定されまたはアクティブにされている「Ｕｓｅ Ｃａｃｈｅ」ビットにより示されるかまたは検出されることが可能なことを思い出さなければならない。ブロック６１４は次いで、その最新のディスプレイを表示する。

ブロック６１２から、フレーム１１８がＩフレームでも、Ｐフレームでも、スーパーＰフレームでもない場合、ブロック６２０はこの他のタイプのフレームを処理することができる。その後、プロセスフロー６００はブロック６０２に戻って次のフレーム１１８を待機することができる。

ブロック６１４から、ブロック６２２は「Ｃａｃｈｅ」ビットがフレーム１１８に対して設定されているかどうかをテストする。そうならば、ブロック６２４はフレーム１１８を、例えば図４に示すキャッシュ４０４などのキャッシュに格納する。ブロック６０２はそして次のフレーム１１８の到着を待機する。ブロック６１４に戻ると、「Ｃａｃｈｅ」ビットがフレーム１１８に対して設定されていない場合、ブロック６２４は飛ばされてもよく、ブロック６０２はそして次のフレーム１１８の到着を待機する。

（結論）
システムおよび方法を構造的特徴および／または方法論的動作に固有な言葉で説明してきたが、添付の特許請求の範囲で定義したシステムおよび方法は説明した特定の特徴または動作に必ずしも限定されないことは理解されるべきである。寧ろ、その特定の特徴および動作は、クレームしたシステムおよび方法を実装する例示的な態様として開示してある。

さらに、本明細書で説明および例示した特定のフロー図に関して、本明細書の説明の精神および範囲から逸脱することなく、その中で示したプロセスおよびサブプロセスは、そられ例示したもの以外の順序で実施できることに留意されたい。

メディアエンコーダとデコーダの間のフィードバックおよびフレーム同期の実施に適した動作環境を示すブロック図である。 その少なくとも一部は図１に示すフレームのそれぞれのインスタンスの実装に適し得るデータ構造を示すブロック図である。 その少なくとも一部は図１に示すフィードバックチャネルのそれぞれのインスタンスの実装に適し得るデータ構造を示すブロック図である。 フレームを受信すること、新規フレームを以前のディスプレイと統合して最新のディスプレイを生成すること、フレームをキャッシュすること、および新規フレームをキャッシュの内容と統合して最新のディスプレイを生成することに対する動作環境を示すブロック図である。 フレームのエンコードとフレーム損失レポートへの応答を実施し得るプロセスフローを示すフロー図である。 例えばデコーダにより受信したフレームを処理するプロセスフローを示すフロー図である。

Claims (8)

1. エンコーダとデコーダとの間でフィードバックおよびフレーム同期を行うために、エンコーダにおいて実行される方法であって、
   ソースコンテンツに基づいて少なくとも１つのフレームをエンコードするステップと、
   前記フレームをエンコーダおよび少なくとも１つのデコーダにキャッシュするかどうかを決定するステップと、
   前記決定に応じて、前記フレームに関連付けられた少なくとも１つのキャッシュ制御ビットをエンコードするステップであって、前記少なくとも１つのキャッシュ制御ビットをエンコードするステップは、前記フレームが前記エンコーダおよび前記デコーダでキャッシュされるべきことを示すように前記キャッシュ制御ビットを設定するステップを含む、エンコードするステップと、
   前記エンコーダで前記フレームをキャッシュするステップと、
   前記フレームを前記デコーダに送信するステップと、
   前記デコーダから、前記エンコーダが送信した一連のフレームのうち少なくとも１つの追加のフレームが失われたかまたは破損したことを報告するデータを含む損失レポートを受信するステップと、
   前記損失レポートの受信に応答して、少なくとも１つのキャッシュしたフレームを参照し、参照フレームに基づいて前記少なくとも１つの追加のフレームに対する置換フレームをエンコードするステップと
   を備え、前記デコーダから、前記デコーダによりサポートされる画素解像度または色深度を表すデータを受信するステップをさらに備えることを特徴とする方法。
2. 前記少なくとも１つの追加のフレームに対する前記置換フレームを前記デコーダに送信するステップをさらに備える請求項１に記載の方法。
3. 前記置換フレームに関連付けられた少なくとも１つの追加のキャッシュ制御ビットを設定するステップをさらに備え、前記追加のキャッシュ制御ビットは、前記参照フレームに基づいて前記置換フレームがエンコードされることを示すことを特徴とする請求項１に記載の方法。
4. 前記少なくとも１つのフレームをエンコードするステップを、前記デコーダの前記画素解像度または前記色深度を表す前記データに基づいて実施することを特徴とする請求項１に記載の方法。
5. エンコーダとデコーダとの間でフィードバックおよびフレーム同期を行うために、デコーダにおいて実行される方法であって、
   ソースコンテンツからエンコードした少なくとも１つのフレームを受信するステップと、
   前記フレームをキャッシュするかどうかを決定するステップであって、前記フレームに関連付けられた少なくとも１つのキャッシュ制御ビットをテストするステップを含む、決定するステップと、
   前記フレームをデコードするステップと、
   前記フレームに関連付けられた少なくとも１つのキャッシュ制御ビットが設定されていると決定したことに応じて、前記フレームをキャッシュするステップと、
   前記エンコーダから送信された一連のフレームのうち少なくとも１つの追加のフレームが失われたかまたは破損したことを報告するデータを含む損失レポートを、前記エンコーダに送信するステップと、
   前記損失レポートの送信に応答して、前記エンコーダから前記少なくとも１つの追加のフレームに対する置換フレームを受信するステップであって、前記置換フレームは、少なくとも１つのキャッシュされたフレームへの参照に基づいてエンコードされている、ステップと
   を備え、前記デコーダがサポートする画素解像度または色深度を表すデータを前記エンコーダに送信するステップをさらに備えることを特徴とする方法。
6. 前記フレームが破損しているかどうかを決定するステップ、および少なくとも１つの追加のフレームが失われているかどうかを決定するステップのうち少なくとも１つをさらに備える請求項５に記載の方法。
7. 前記フレームに関連付けた少なくとも１つのキャッシュ制御ビットをテストすることで、キャッシュした参照フレームに基づいて前記フレームをエンコードするかどうかを決定するステップをさらに備える請求項５に記載の方法。
8. 前記置換フレームを少なくとも１つのキャッシュした内容と統合するステップをさらに備える請求項５に記載の方法。

Images