損失の多いネットワークを通してデータを送信するためのシステム及び方法
【課題】損失の多いワイヤレスネットワークを通した送信失敗の確率を下げるために使用可能なエンコーダ／デコーダシステムを提供する。
【解決手段】ある実施形態において、そのワイヤレスネットワークを通して送信が失敗したデータパケットは、その失われたパケット内のデータがどれほど重要であるかに依存して、ある特定の回数、再送信可能である。別の実施形態では、後続の予測操作に複数の参照フレームが使用されるべきであることをサーバ側へ信号送信することによって、クライアント側における復号正鵠の確率は改善可能である。
【解決手段】ある実施形態において、そのワイヤレスネットワークを通して送信が失敗したデータパケットは、その失われたパケット内のデータがどれほど重要であるかに依存して、ある特定の回数、再送信可能である。別の実施形態では、後続の予測操作に複数の参照フレームが使用されるべきであることをサーバ側へ信号送信することによって、クライアント側における復号正鵠の確率は改善可能である。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は広く、損失の多いネットワークを通してデータを送信することに関し、特に、損失の多いワイヤレスネットワーク接続を通してデータ送信動作を改善することに関する。
【背景技術】
【０００２】
ワイヤレスネットワークを通して圧縮ビデオを送信することに関連する典型的な問題は、サービスの質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ：ＱｏＳ）と、待ち時間と、基本画像完全性を維持することとを含む。例えば、もし送信されたビデオデータの単一のパケットが失われるなら、ビデオデータは一時的な領域において典型的に圧縮されるという事実が、１つのフレームから複数の連続するフレームにわたって、単一のアーチファクトの伝播とカスケード化とを引き起こす。ＩＥＥＥ８０２．１１ｘ及び８０２．１５．３ａによって記述されるようなワイヤレスプロトコルと、ＡＶＣビデオ規格によって記述されるもののようなビデオ圧縮アルゴリズムとを、このような損失の多いワイヤレスネットワークで操作する場合がある。損失の多いネットワークを、例えばホームプラグＡＶ電力線通信（ＨｏｍｅＰｌｕｇ ＡＶ Ｐｏｗｅｒｌｉｎｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）のような、ワイヤレス以外の送信方法に使用する場合もある。
【０００３】
損失の多いネットワークを通したビデオ送信の間に、（「ビデオパケット」と称する場合もある）ビデオデータが失われる場合がある。例えば、損失の多いワイヤレス送信媒体では、送信されたビデオパケットはワイヤレス受信機によって（正確にまたは完全に）受信されることが常に可能というわけではなく、そのような送信媒体は信頼できない場合がある。これに対応するために、ほとんどの場合において、「ＡＣＫ」信号を返送することにより、受信されるパケット（または標準の拡張８０２．１１ｅにおいてはパケットのグループ）が送信機に確認されることを、８０２．１１ｘ媒体アクセス制御（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ：ＭＡＣ）は必要とする。ゆえに、ＡＣＫ信号の欠損は普通、ビデオパケットが失われてしまっていることを示す。
【０００４】
加えて、ビデオパケットデータは受信機においてもまた失われる場合がある。例えば、応用ビデオ符号化（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ：ＡＶＣ）で符号化されたデータはバースト性をもつ傾向があるため、予想外に大きなバーストが、８０２．１１ｘモジュールとＡＶＣデコーダ自体との間のいくつかの場所において受信機側のバッファをオーバーフローさせる場合がある。このようにして失われたほとんどのパケットは、リアルタイムトランスポートプロトコル（Ｒｅａｌ‐Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ：ＲＴＰ）フィードバックによって検出可能である。
【０００５】
損失の多いネットワーク通信に関連する内在的な欠点のいくつかを緩和するために、様々なデータリカバリとエラー訂正との特徴が、使用されるデータ符号化規格に組み込まれてきた。例えば、Ｈ２６４／ＡＶＣは最近開発された符号化規格であり、ビデオコンテンツを効果的に表すためのビデオ符号化レイヤ（Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｌａｙｅｒ：ＶＣＬ）と、ビデオのＶＣＬ表示をフォーマットし、特定のトランスポートレイヤによる輸送または記憶媒体に適した方法でヘッダ情報を提供するためのネットワーク抽象レイヤ（Ｎｅｔｗｏｒｋ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ：ＮＡＬ）とを含む。これらの努力にかかわらず、８０２．１１ｘネットワークのような損失の多いネットワーク接続を通した送信信頼性とエラー隠蔽とを改善する必要がある。
【０００６】
送信失敗の確率を下げる、及び／または復号成功の確率を向上させる、及び／または受信機側におけるエラー隠蔽の質を上げるように、ネットワークを通してビデオデータを送信する改善されたシステム及び方法の必要性は、このように、未だ満たされていない。
【発明の概要】
【課題を解決するための手段】
【０００７】
ワイヤレスネットワークのような、損失の多いネットワークを通してデータを送信するためのシステム及び方法がここで開示され、請求される。ある実施形態においては、１つのネットワークを通して符号化されたデータパケットを送信することと、もし符号化されたデータパケットがうまく送信されたならば、肯定確認応答信号（ａｃｋｎｏｗｌｅｄｇｍｅｎｔ ｓｉｇｎａｌ）を受信することと、もし肯定確認応答信号が受信されないならば、再送信試行の数を決定することとを、方法が含み、その再送信試行の数は、符号化されたデータパケット内のデータの種類に少なくとも部分的に基づく。
【０００８】
他の実施形態がここで開示され、請求される。
【図面の簡単な説明】
【０００９】
【図１】図１は、この発明の１つまたはそれ以上の側面の実施形態のための単純化されたシステム概観のある実施形態を表す。
【図２】図２は、ある実施形態に従って本発明のある側面を伝えるための処理を表す。
【図３】図３は、ある実施形態に従って本発明のある側面を伝えるための処理を表す。
【図４】図４は、ある実施形態に従って本発明の別の側面をなお伝えるための処理を表す。
【図５】４個のフィールドからなる１つの実施形態を表す。
【図６】ＩＤＲフレーム６００の別の実施形態を表す。
【発明を実施するための形態】
【００１０】
本発明は、サーバから１つまたはそれ以上のクライアント側のシステムへ、損失の多いネットワークを通して少なくとも部分的にワイヤレスでデータ（例えばビデオデータ）が送信されているシステムに関する。ある実施形態においては、サーバはエンコーダモジュールと送信機とを含み、一方でクライアントはデコーダモジュールと受信機とを含む。
【００１１】
本発明のある側面によれば、サーバによってワイヤレスネットワークを通して送信され、うまく受信されないデータパケットは、特定の回数、再送信可能である。ある実施形態において、再送信試行の数は、失われたパケット内のデータがどのくらい重要であると見なされるかに基づく。つまり、ある実施形態において、再送信試行の数は適応性を持ち得て、より重要であると見なされたパケット（例えばＩＤＲフレームを含むもの）は、より重要でないパケット（例えばＰフレームを含むもの）と比べてより多くの回数、再送信される。ある実施形態において、前述のデータパケットは、Ｈ．２６４／ＡＶＣエンコーダによって符号化されても良く、及び／または８０２．１１ｘワイヤレスネットワーク接続を通して送信され、１つまたはそれ以上のＨ．２６４／ＡＶＣデコーダによって復号されても良い。
【００１２】
本発明の別の側面は、復号成功の確率をクライアント側において改善することである。ある実施形態において、複数の参照フレームを後続の予測操作に使用するよう、対応するエンコーダに対しデコーダに信号送信させることによって、復号成功の確率改善は行われる。これにより、Ｈ．２６４／ＡＶＣシステムの場合において、前のフレーム内（または、Ｂフレームの場合には後来のフレームも）のデータを参照するＰフレームのようなフレームが、複数の参照フレーム内のマクロブロックを参照して、現フレーム内のマクロブロックを判定することが可能になる。
【００１３】
別の実施形態において、元のデータストリームのどのスライスがデコーダにおいて受信されていないか正確に識別することによって、クライアント側における復号成功の確率は改善可能である。ある実施形態において、与えられるパケットに対する肯定確認応答信号はいつ受信されず、パケット再送信試行はいつ全部使用されてしまったかを指摘することによって、クライアント側における復号成功確率の改善は実行可能である。この情報を使用して、エンコーダはその後、これらの失われたスライス／マクロブロックを後来の符号化操作において参照することを中止できる。これによって、クライアント側において後来の復号されたフレームへのエラーの伝播を制限することが可能である。ある実施形態において、この制限は前述の操作と同時に行われる場合がある一方、別の実施形態においては、この制限は後に行われる場合もある。
【００１４】
なお本発明の別の側面は、失われたデータパケット／スライスによって引き起こされるデータの歪みを推定することである。この情報を使用すると、クライアントにおけるエラー隠蔽によって適切に再構築されていると見なされる過去のピクセルが参照され続けることが可能となり、一方で適切に再構築されてはいないデータへの参照は適切に回避されることが可能となる。ある実施形態において、何のエラー隠蔽が使用されたかをクライアントデコーダが正確に知っているとすると、クライアント自体がサーバへ歪みのレベルを示し返すことが可能である。この情報は従ってサーバに返信可能である。しかし、別の実施形態においては、任意の失われたデータパケットに対する、クライアントにおけるエラー隠蔽を推定することによって、受信されたデータのエラーの推定はまたサーバ側で判定可能であって、サーバにおいてまた使用可能である元のデータと再構築されたデータとを比較することによって、歪みが推定されることは従って可能である。
【００１５】
なお本発明の別の側面は、Ｈ．２６４／ＡＶＣのエンコーダ／デコーダシステムの柔軟マクロブロック順序（Ｆｌｅｘｉｂｌｅ Ｍａｃｒｏｂｌｏｃｋ Ｏｒｄｅｒｉｎｇ：ＦＭＯ）機能を使用することによって、クライアントにおけるエラー隠蔽の質を上げることである。つまり、ＩＤＲフレームの全部のマクロブロックが複製なしでｎ個のフィールドに含まれることが可能となるように、まずは各ＩＤＲフレームをｎ個のフィールドに分解することによって、（ピクチャ内の全部の連続するフレームが依存する）ＩＤＲフレームの再構築がより強固となることが可能である。その後、各フィールドはｍ個のスライスにセグメント化されても良い。ある実施形態において、第１のフィールドに代わる全部のｍ個のスライスは最初に送信され、その後に第２のフィールドに代わる全部のｍ個のスライスの送信が続き、そして全部のｎ個のフィールドに代わる全部のｍ個のスライスが送信されてしまうまで、以下同様に続くことが可能である。損失の多いネットワーク環境（例えば８０２．１１ｘ）におけるエラーにはしばしばバースト性があり、エラーの短いバーストは、例えば任意のフィールドに代わる全部のｍ個のスライスを削除するため、各フィールドのスライスを順次送信することは望ましい場合がある。そうであれば、もし異なるフィールド（例えば１と３と４等）に代わるｍ個のスライスが正しく受信されているならば、デコーダ（例えばＨ．２６４／ＡＶＣデコーダ）のエラー隠蔽機能が隣接ピクセルを補間し、欠損ピクセルを推定できる。なぜなら、欠損マクロブロックは使用可能なマクロブロックによって空間的に包囲されているからである。
【００１６】
本発明の前述の側面の全部またはいくつかは、Ｈ．２６４／ＡＶＣのエンコーダ／デコーダシステム及び／または８０２．１１ｘワイヤレスネットワーク接続を使用して実施可能であるいうことが認識されるべきである一方、前述の側面は、他の同様のコーデック及び／または損失の多い通信チャネルを使用しても実施可能であるということがまた同様に認識されるべきである。
【００１７】
ソフトウェアにおいて実施されるとき、本発明の要素は本質的に、必要なタスクを行うためのコードセグメントである。プログラムまたはコードセグメントは処理装置読み取り可能媒体（ｐｒｏｃｅｓｓｏｒ ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）に記憶可能である、または、送信媒体または通信リンクを通るキャリア波において具体化されるコンピュータデータ信号によって送信可能である。
（Ｈ．２６４／ＡＶＣ概観）
【００１８】
Ｈ．２６４／ＡＶＣ規格は、プログレッシブまたはインターレースフレームのいずれか、または同じシーケンス中において共に混合された両方を含むビデオ符号化を支援する。一般的に、ビデオのフレームは２つのインターリーブフィールド――上端及び下端フィールド――を含む。インターレースフレームの２つのフィールドは、フィールド期間で時間的に分離され、２つのフィールドピクチャとして別々に符号化されても良く、または共に１つのフレームピクチャとして符号化されても良い。一方、プログレッシブフレームは単一のフレームピクチャとして符号化される。しかしそれは依然として、時間的に同じ瞬間に２つのフィールドからなると見なされる。
【００１９】
ＶＣＬは、以下でより詳細に記述されるが、ビデオデータのコンテンツを表す。対照的に、ＮＡＬはデータをフォーマットし、トランスポートレイヤによる輸送または記憶媒体に適した方法でヘッダ情報を提供する。全部のデータはＮＡＬユニットに含まれて、その各々は整数個のバイトを含む。ＮＡＬユニットは、パケット指向及びビットストリームシステムの両方における使用のための一般的フォーマットを特定する。
【００２０】
Ｈ．２６４／ＡＶＣ規格のＶＣＬは、ＭＰＥＧ−２のような他の規格と本質的に同様である。要するに、変換符号化と併せて、それは一時的で空間的な予測の混成からなる。ビデオの各ピクチャは、フレームである場合またはフィールドである場合があり、固定サイズのマクロブロックにパーティション化される。そのマクロブロックは、ルーマ（ｌｕｍａ）成分の１６×１６サンプルと、２つのクロマ（ｃｈｒｏｍａ）成分の各々の８×８サンプルとの矩形ピクチャエリアを覆う。マクロブロックの全部のルーマ及びクロマサンプルは、空間的にまたは一時的に予測され、結果の予測残余は変換符号化を使用して送信される。
【００２１】
マクロブロックは、独立して復号可能である任意のイメージの部分を表すスライスにまとめられ、ビットストリームにおけるマクロブロックの送信順序はマクロブロック割り当てマップに依存する。Ｈ．２６４／ＡＶＣ規格は５つの異なるスライス符号化種を支援する。最も単純なものはＩスライス、すなわちイントラスライス（Ｉｎｔｒａ ｓｌｉｃｅ）と呼ばれる。Ｉスライスにおいて、全部のマクロブロックは、ビデオシーケンス内の他のピクチャを参照することなく符号化される。一方、予測符号化されるＰ及びＢスライス（Ｐは予測（ｐｒｅｄｉｃｔｉｖｅ）を表し、Ｂは双予測（ｂｉ‐ｐｒｅｄｉｃｔｉｖｅ）を表す）のマクロブロックにための予測信号を形成するために、先に符号化されるイメージが使用可能である。２つの追加のスライス種はＳＰ（ｓｗｉｔｃｈｉｎｇ Ｐ）とＳＩ（ｓｗｉｔｃｈｉｎｇ Ｉ）とであり、様々なビットレートで符号化されるビットストリーム間の効果的なスイッチングを指定する。
【００２２】
ピクチャ内のマクロブロックを１つまたはいくつかのスライスグループに割り当てるパターンが指定される柔軟マクロブロック順序（ＦＭＯ）と呼ばれる特徴を、Ｈ．２６４／ＡＶＣ規格は支援する。各スライスグループはその後別々に送信可能である。
（システムアーキテクチャ概観）
【００２３】
図１は、本発明の１つまたはそれ以上の側面を実行するためのシステム１００のある実施形態を表す。具体的にはシステム１００は、ソース１００からのビデオコンテンツのキャプチャを含む。ある実施形態において、ビデオコンテンツ１１５は、リアルタイムビデオソースから送信されるリアルタイムコンテンツである場合がある。ビデオコンテンツ１１５は、リアルタイムコンテンツであるか否かにかかわらず、図１の実施形態においてエンコーダ１２０と送信機１３０とを含むサーバ１３５へ、提供可能である。ある実施形態において、エンコーダ１２０はソース１１０からのビデオコンテンツ１１５を処理し、ネットワーク１４０を介して、ある目的地点に符号化されたデータ１２５を提供する。ある実施形態においては、エンコーダ１２０は、前述のＨ．２６４／ＡＶＣ符号化規格に従ってビデオコンテンツ１１５を符号化しても良い。しかし、本発明はＨ．２６４／ＡＶＣ符号化規格以外のコーデックを用いて使用可能であることが同様に認識されるべきである。
【００２４】
図１において示されるように、ひとたび符号化されると、符号化されたデータ１２５は送信機クライアント１４５へ提供される。ある実施形態において送信機１３０は８０２．１１ｘまたは８０２．１５．３ａワイヤレス送信機であるが、送信機１３０は、数多くの他の損失の多いプロトコルに従ってデータを送信しても良いことがまた同様に認識されるべきである。使用されるワイヤレスプロトコルにかかわらず、符号化されたデータ１２５はネットワーク１４０に提供され、ネットワーク１４０を通して送信可能である。ある実施形態において、エンコーダ１２０は、前述のＨ．２６４／ＡＶＣ符号化規格に従ってビデオコンテンツ１１５を符号化できる。しかし、Ｈ．２６４／ＡＶＣ符号化規格以外の同様のコーデックと、８０２．１１ｘ／８０２．１５．３ａワイヤレスネットワーク以外の損失の多いネットワークとを用いて、本発明は使用可能であるということが同様に認識されるべきである。
【００２５】
図１の参照を続けると、クライアント１４５は受信機１５０とデコーダ１５５とを含む。符号化されたデータ１２５は、ネットワーク１４０（例えばインターネット）と通信中の受信機１４５によって受信可能である。すると受信機１５０は符号化されたデータ１２５をデコーダ１５０へ提供する。別の実施形態においては、符号化されたデータ１２５はクライアント側の複数の装置（示されず）によって受信され、復号されても良い。図１において示されるように、エンコーダ１２０によって使用される符号化規格（例えばＨ．２６４／ＡＶＣ）に依存して、デコーダ１５５はその後、符号化されたデータ１２５の特別な復号操作を行って、接続されるディスプレイ１６５へ復号されたビデオコンテンツ１６０を提供することが可能である。
【００２６】
サーバ１３５とクライアント１４５とは、図１に表される以外の数多くの構成が可能であるということが認識されるべきである。例えば、エンコーダ１２０と送信機１３０とのいずれかまたは両方は、サーバ１３５から分離されても良い。同様に、デコーダ１５５と受信機１５０とのいずれかまたは両方は、クライアント１４５に集積されなくても良い。
【００２７】
示されてはいないが、計算とデータの一時的な記憶のためのレジスタの収集と命令とを行うための数値演算装置（ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ：ＡＬＵ）を含むことが可能である中央処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ：ＣＰＵ）と、コンピュータシステムの制御操作のための制御装置とのような他の成分を、サーバ１３５及び／またはクライアント１４５は含むことが可能であるということが同様に認識されるべきである。ある実施形態において、ＣＰＵは、ｘ８６、またはインテル（登録商標）社（ＩｎｔｅｌTMＣｏｒｐｏｒａｔｉｏｎ）によって販売されるＰｅｎｔｉｕｍTM級マイクロプロセッサ、またはＡＭＤTMによって販売されるマイクロプロセッサ、またはサイリックス（登録商標）社（ＣｙｒｉｘTMＣｏｒｐ．）よって販売される６ｘ８６ＭＸマイクロプロセッサのどの１つでも良い。加えて、ＭＩＰＳ、ＩＢＭ、モトローラ（Ｍｏｔｏｒｏｌａ）、ＮＥＣ、サイリックス、ＡＭＤ、ネクスジェン（Ｎｅｘｇｅｎ）他からのものを含む様々な他のプロセッサのいずれも使用可能である。さらに、このようなＣＰＵのいずれもマイクロプロセッサに限定される必要はなく、マイクロコントローラ、デジタル信号プロセッサ、縮小命令セットコンピュータ（ｒｅｄｕｃｅｄ ｉｎｓｔｒｕｃｔｉｏｎ ｓｅｔ ｃｏｍｐｕｔｅｒｓ：ＲＩＳＣ）、アプリケーション固有の集積回路、そしてそれらの類似のもののような、他の形態をとっても良い。
【００２８】
サーバ１３５及び／またはクライアント１４５が含むことができる他の成分は、ランダムアクセスメモリと、不揮発性記憶装置（例えばハードディスク、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、テープ、高密度フロッピー（登録商標）、高容量リムーバブルメディア、低容量リムーバブルメディア、固体記憶装置等、そしてそれらの組み合わせ）とである。サーバ１３５及び／またはクライアント１４５は、またネットワークインターフェース（例えばネットワークインターフェースカード、モデムインターフェース、統合サービスデジタル通信網等）と、ユーザ入力装置（例えば、命令と交流し、提供することをユーザに可能にするキーボード、マウス、ジョイスティック、そしてその類似のもの）とを含んでも良い。
【００２９】
サーバ１３５及び／またはクライアント１４５は、サーバ１３５及び／またはクライアントの作動と資源の割り当てとを制御するための、システムＢＩＯＳのようなシステムファームウェアとオペレーティングシステム（例えばＤＯＳ、ウインドウズ（Ｗｉｎｄｏｗｓ（登録商標））、ユニックス（Ｕｎｉｘ（登録商標））、リナックス（登録商標）（Ｌｉｎｕｘ（登録商標））、ゼニックス（Ｘｅｎｉｘ）等）とを含んでも良いということがさらに認識されるべきである。
（送信失敗の確率低下）
【００３０】
上で言及したように、本発明のある側面は送信失敗の確率を低下可能とすることである。そのために、図２は本発明のある実施形態に従って、処理２００を示し、送信失敗の確率がどのようにして低下可能となるかを表す。リアルタイムワイヤレス送信について言えば、全部のデータパケットの送信成功を保障することは必ずしも実行可能とは限らない。具体的には、過剰な冗長送信が、許容できない待ち時間につながる場合がある。そういうことで、いくつかのデータパケットは他よりも重要であると見なされる場合がある。ゆえに、再送信試行の数は、問題のパケットの重要性の関数となり得る。例えば、瞬時デコーダリフレッシュ（Ｉｎｓｔａｎｔａｎｅｏｕｓ Ｄｅｃｏｄｅｒ Ｒｅｆｒｅｓｈ：ＩＤＲ）フレームを含むパケットは、予測（ｐｒｅｄｉｃｔｉｖｅ）フレーム、すなわちＰフレームを含むもののような、より重要でないパケットと比べてより多くの回数、再送信されることができる。そのために、処理２００は、データパケットの送信についてのブロック２１０から始まる。その後ブロック２２０にて、パケットが受信されたかどうかに関する判定が行われる。ある実施形態において、この判定は、目的地点の受信機（例えばクライアント１４５）がソース（例えばサーバ１３５）へＡＣＫ信号を返したかどうかに基づく場合がある。しかし、パケット配信成功はまた他の手段を使用して判定されても良いことが同様に認識されるべきである。
【００３１】
もし問題のパケットが実際に受信されたとブロック２２０で判定されるならば、処理２００は単純にブロック２３０へ移行し、次のデータパケットが処理される。一方、パケットが適切に受信されなかったと判定される場合には、処理２００はブロック２４０へ続き、そのパケットに対して再送信が何回試行されるべきかに関する決定が実行可能である。ある実施形態において、再送信試行の数は、そのパケット内に含まれるデータの重要性に基づく。別の実施形態においては、再送信が実行されて発生する全部のレベルにおいて、再送信の数は適応可能となることができる。例えば、再送信の数は、８０２．１１ｘＭＡＣレイヤに適応可能となっても良く、信頼できるまたは半分信頼できるＲＴＰ再送信の形が実施されている場合には、同様にＲＴＰレイヤに適応可能となっても良い。
【００３２】
ひとたびパケットの再送信の数が決定されてしまうと、処理２００はブロック２５０へ続き、そのパケットが再送信されるべきかどうかが判定される。もし再送信試行の数が零に等しければ、そのパケットは再送信されず、処理２００は終了する。一方、もし再送信試行の数が零より多ければ、処理２００はブロック２６０へ続き、パケットが再送信され、その後残りの再送信試行の数が１減る（ブロック２７０）。ひとたび再送信されると、その後ブロック２８０にて、再送信されたパケットが今回で受信されたかどうかに関する判定が行われなければならない。もし受信されたならば、処理２００は単純にブロック２３０へ移行し、次のデータパケットが処理される。もし受信されていなければ、処理２００はブロック２５０に戻り、パケットが再送信されるべきかどうかが判定される（すなわち、再送信試行の数が零と等しいか否かを判定する）。
（復号成功の確率上昇）
【００３３】
上で言及したように、本発明の別の側面は、損失の多い送信のクライアント側における復号成功の確率を上げることである。そのために、損失の多いネットワーク（例えばネットワーク１４０）を通して送信されるビデオコンテンツの復号を改善するための処理３００のある実施形態を、図３は示す。具体的には、処理３００は、送信失敗の数が増加しているかどうかの判定から始まる。例えばクライアント側の装置（例えばクライアント１４５）によって送信されるＡＣＫの数の減少を検出することによって、送信失敗の数の増加の判定は行われることが可能である。ある実施形態において、対するＡＣＫの数を比較するために、既定の閾値が使用可能である。ひとたびＡＣＫの数（または任意の時間毎にＡＣＫが受信されるレート）が、既定の閾値を下回ると、処理３００は、ブロック３１０及び３２０及び３３５の内１つまたはそれ以上へ続く。つまり、処理３００の部分は同時にまたは連続的に実行可能である。例えば、ブロック３１０〜３１５を含む処理３００の部分は、ブロック３２０〜３３０及び／またはブロック３３５〜３４５を参照して以下に説明される操作と同時に実行できる。
【００３４】
ひとたびＡＣＫの数（またはＡＣＫの受信レート）が、既定の閾値を下回ると、クライアントすなわちデコーダ側は、エンコーダへ、そのエンコーダが予測の目的で複数の参照フレームを使用すべきであると信号を送り返す。例えば、Ｈ．２６４／ＡＶＣエンコーダの場合、前のフレーム（またはＢフレームの場合には後来のフレームも）内のデータを参照するＰフレームは、現フレーム内のマクロブロックを判定するために、複数の参照フレーム内のマクロブロックを参照する。ゆえに、損失の多い送信エラーが原因で参照フレームの１つが欠損する場合において、他の参照フレームまでは失われていないと仮定すると、現フレームはまだうまく再構築される可能性がある。
【００３５】
このように、複数の参照フレームを使用する（ブロック３１５）ことによって、予想される後来のフレームの破損につながるカスケーディング効果（ｃａｓｃａｄｉｎｇ ｅｆｆｅｃｔ）を、失われたフレームが引き起こす確率は、効果的に低下可能である。ブロック３１５から通じる進行破線によって示されるように、ブロック３１０〜３１５の操作は、ブロック３２０〜３３０及び３３５〜３４５を参照して以下に記述される操作と同時にまたは連続的に実行可能である。
【００３６】
連続的に行われるか同時に行われるかにかかわらず、ブロック３２０において、元のビデオストリームのどのスライスがデコーダで受信されていないのかを、サーバ側（例えばサーバ１３５）は正確に識別する。ある実施形態においては、８０２．１１ｘＭＡＣレイヤにおいてそのパケットに対してＡＣＫ信号は受信されてはいないことから、サーバはどのデータパケットが失われているかを認知している、またはサーバはＲＴＰアプリケーションレイヤにおいてどのＲＴＰパケットが失われているかを認知しているので、この情報は使用可能である。ひとたび欠損スライスが識別されてしまうと、処理３００はブロック３２５へ続くことが可能であり、どのスライス（ゆえにどのマクロブロック）がデコーダによって受信されていないかを、エンコーダは通知されることが可能である。この情報を使用して、（ある実施形態においてＨ２．６４／ＡＶＣエンコーダである）エンコーダは、後来のＰ及びＢフレーム内のこれらの失われたスライス／マクロブロックを参照することを中止する（ブロック３３０）。別の実施形態においては、エンコーダは、必要ならばまた追加のＩＤＲフレームを生成しても良い。
【００３７】
処理３００の前述の操作と同時にまたは連続的にブロック３３５において、欠損パケットによって引き起こされる歪みのレベルが、サーバによって推定可能である。全部の失われたパケットが同様にビデオを劣化させるわけではなく、特に、多くのデコーダ（例えばＨ２６４デコーダ）はエラー隠蔽を使用するため、この歪みレベル推定可能性は重要である場合がある。ある実施形態においては、失われたパケットによって引き起こされるクライアントのビデオの歪みを、クライアント自体が推定できる。デコーダが、知的財産権を有する場合もあり得るエラー隠蔽をどのように実施してきたかを、自身で正確に認知するため、このクライアント自身による推定は好ましい場合がある。この場合、歪みのレベルはサーバへ返信される（ブロック３４０）。
【００３８】
代替として、クライアントとサーバ間の通信のこのバックチャネルは信用できない場合がある。その場合、その任意の失われたスライス／パケットに対するクライアントにおけるエラー隠蔽を推定することによって、最終のビデオのエラーの推定はまたサーバで判定されても良い。サーバでも同様に使用可能である元のビデオと再構築されたビデオとを比較することによって、歪みは推定可能である。歪みがクライアント側で推定されたか、サーバ側で推定されたかにかかわらず、この情報はその後エンコーダによって使用され、クライアントにおけるエラー隠蔽によって適切に再構築されたと見なされる過去のピクセルのみ参照可能となる（ブロック３４５）。
【００３９】
リアルタイムビデオコンテンツに加えて、図３の処理３００は、あらかじめ記憶されるストリームに対し、（ＰＶＲまたはＩＳＰヘッドエンドのような）サーバ側でもまた実施可能である。この場合、同じ符号化されたストリームのバージョンがいくつかあらかじめ記憶可能となり、それにより、符号化されたデータのこのような複数のバージョンをオンザフライで作成する待ち時間が減少可能となる。コンテンツがリアルタイムで符号化されている他の場合において、待ち時間によって重大な影響を受けやすいアプリケーションについては、複数の符号化されたストリーム（例えばＨ．２６４／ＡＶＣ）の間でスイッチングを可能にして、上に説明されたような特定の失われたスライスのいずれかへの依存性を制限することによって、それらを同時に生成することが好ましい場合がある。
（エラー隠蔽の質の向上）
【００４０】
上で言及したように、本発明の別の側面は、損失の多い送信のクライアント側におけるエラー隠蔽の質を上げることである。そのために、エラー隠蔽を使用して、欠損マクロブロックによって引き起こされるビデオコンテントの歪みを減らす処理４００のある実施形態を、図４は示す。Ｈ．２６４／ＡＶＣエンコーダの場合、柔軟マクロブロック順序（ＦＭＯ）が使用可能である。図４の処理４００を使用すると、（ピクチャ内の全部の連続するフレームが依存する）ＩＤＲフレームの再構築が、より強固となる場合がある。具体的には、処理４００は、ブロック４１０において、各ＩＤＲフレームをｎ個のフィールドに分解することから始まる。図５を参照して以下に示されるように、ｐ個のマクロブロックによって他のマクロブロックから空間的に分離されるマクロブロックを、各フィールドは含むことができる。ゆえに、ＩＤＲフレームの全部のマクロブロックは、複製なしで、ｎ個のフィールドに含まれることができる。その後ブロック４２０において、ＮＡＬによって、各フィールドはｍ個のスライスにセグメント化されることが可能であり、その場合ワイヤレスネットワーク（例えば８０２．１１ｘ）リンクレイヤによって、サイズ制限が課される。
【００４１】
ひとたびフィールドがｍ個のスライスにセグメント化されてしまうと、処理４００はブロック４３０に続くことが可能であり、１番目のフィールドに代わる全部のｍ個のスライスが最初に送信可能であり、その後に２番目のフィールドに代わる全部のｍ個のスライスの送信が続き、全部のｎ個のフィールドに代わる全部のｍ個のスライスが送信されてしまうまで以下同様に続く。損失の多いネットワーク（例えば８０２．１１ｘ）を通した送信に、この送信形態は特に有用である場合があって、そのようなネットワークにおいては、しばしばエラーがバースト性をもち、エラーの短いバーストが、任意のフィールドに代わる全部のｍ個のスライスを消去する。しかし、異なるフィールド（例えば１と３と４等）に代わるｍ個のスライスが正しく受信されている場合には、使用可能なマクロブロックに欠損マクロブロックが空間的に隣接している、または包囲されていると仮定すると、デコーダ（例えばＨ．２６４／ＡＶＣデコーダ）のエラー隠蔽機能は隣接ピクセルを補間し、欠損ピクセルを推定可能であろう。複製データを送信して、失われたパケットまたはスライスを補う必要性を、このアプローチは回避し、ゆえにその必要な帯域幅はより小さい。別の実施形態においては、単一のマクロブロックがｎ個のマクロブロックによって分離される代わりに、単一のマクロブロックはそれ自体その元のマクロブロックの周りのマクロブロックの組を含むまで拡張されても良い。
【００４２】
別の実施形態において、ネットワークの他のステージにて重大な混雑が発生するならば、図４の符号化処理４００はまたバッファ管理とストリーミングスタックとを援助して、データのどのパケットがドロップ可能であるかを、ワイヤレス送信前に（またはワイヤレス受信の後に）判定することが可能である。元のストリーム内のパケットをどれでもランダムにドロップすることと比べると、フレームのフィールドの１つを含むネットワークパケットをドロップすることによって、受信機においてビデオ復号のより良い質が得られる結果となる場合がある。空間的多重化ＭＩＭＯワイヤレス技術が使用される特定のアプリケーションに対して、動作をさらに改善するために、空間的に別々のチャネル上で各フィールドを任意に送信することが可能であることがさらに認識されるべきである。
【００４３】
前述の処理４００はＩＤＲフレームについて記述されたが、使用可能な帯域幅と計算資源（ｃｏｍｐｕｔａｔｉｏｎａｌ ｒｅｓｏｕｒｃｅｓ）とが許す限り、空間的なイントラフレームデータを含むどんな種類のデータフレームを用いても、この処理４００は使用可能であるということがさらに認識されるであろう。
【００４４】
ここで図５を参照すると、４個のフィールドからなる１つの実施形態が表されており、ｐ＝１のマクロブロックによって、いずれか１つのフィールドの個別のマクロブロックは、水平方向及び垂直方向の両方において、各々から空間的に分離される。図５に示されるように、例えば、フィールド＃３は、「３」とラベルされる全部の個別のマクロブロックからなる。この方法において、フィールド＃３は複数のスライス／パケットで送信され、デコーダ側のエラー隠蔽機能を改善することによって、バースト性エラーの影響を減らすことが可能である。
【００４５】
図６はＩＤＲフレーム６００の別の実施形態を表す。しかし、図６の実施形態においては、ＩＤＲフレーム６００は複数の「スーパーマクロブロック（ｓｕｐｅｒ‐ｍａｃｒｏｂｌｏｃｋｓ）」からなる。この実施形態において、スーパーマクロブロックは４個の別々のマクロブロックで構成され、それらは皆、同じフィールドに対するデータを含む。このように、例えば＃１とラベルされる全部のスーパーマクロブロックはフィールド＃１の部分と見なされ、１つまたはそれ以上のスライスとして順に送信される。その後、（対応して、＃２とラベルされるスーパーマクロブロックからなる）フィールド＃２についても同様に行われ、その後フィールド＃３以下同様である。図５のマクロブロックベースのアルゴリズムと比較されると、図６のスーパーマクロブロックアルゴリズムは符号化効率を上げる傾向があるだろうが、しかし送信中にフィールドが失われた場合、デコーダにおける再構築の正確性は落ちるであろう。
【００４６】
以上、本発明について、さまざまな実施形態について説明してきたが、本発明は、さらなる変更が可能であることを了解されたい。本出願は、本発明のさまざまな変形例、用途、適応例を包含すること、および、本発明の原理に従う限り、本発明の属する技術分野における既知のおよび慣習的な実施範囲における本発明の開示内容からの逸脱を含むことを意図してなされたものである。
【技術分野】
【０００１】
本発明は広く、損失の多いネットワークを通してデータを送信することに関し、特に、損失の多いワイヤレスネットワーク接続を通してデータ送信動作を改善することに関する。
【背景技術】
【０００２】
ワイヤレスネットワークを通して圧縮ビデオを送信することに関連する典型的な問題は、サービスの質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ：ＱｏＳ）と、待ち時間と、基本画像完全性を維持することとを含む。例えば、もし送信されたビデオデータの単一のパケットが失われるなら、ビデオデータは一時的な領域において典型的に圧縮されるという事実が、１つのフレームから複数の連続するフレームにわたって、単一のアーチファクトの伝播とカスケード化とを引き起こす。ＩＥＥＥ８０２．１１ｘ及び８０２．１５．３ａによって記述されるようなワイヤレスプロトコルと、ＡＶＣビデオ規格によって記述されるもののようなビデオ圧縮アルゴリズムとを、このような損失の多いワイヤレスネットワークで操作する場合がある。損失の多いネットワークを、例えばホームプラグＡＶ電力線通信（ＨｏｍｅＰｌｕｇ ＡＶ Ｐｏｗｅｒｌｉｎｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）のような、ワイヤレス以外の送信方法に使用する場合もある。
【０００３】
損失の多いネットワークを通したビデオ送信の間に、（「ビデオパケット」と称する場合もある）ビデオデータが失われる場合がある。例えば、損失の多いワイヤレス送信媒体では、送信されたビデオパケットはワイヤレス受信機によって（正確にまたは完全に）受信されることが常に可能というわけではなく、そのような送信媒体は信頼できない場合がある。これに対応するために、ほとんどの場合において、「ＡＣＫ」信号を返送することにより、受信されるパケット（または標準の拡張８０２．１１ｅにおいてはパケットのグループ）が送信機に確認されることを、８０２．１１ｘ媒体アクセス制御（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ：ＭＡＣ）は必要とする。ゆえに、ＡＣＫ信号の欠損は普通、ビデオパケットが失われてしまっていることを示す。
【０００４】
加えて、ビデオパケットデータは受信機においてもまた失われる場合がある。例えば、応用ビデオ符号化（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ：ＡＶＣ）で符号化されたデータはバースト性をもつ傾向があるため、予想外に大きなバーストが、８０２．１１ｘモジュールとＡＶＣデコーダ自体との間のいくつかの場所において受信機側のバッファをオーバーフローさせる場合がある。このようにして失われたほとんどのパケットは、リアルタイムトランスポートプロトコル（Ｒｅａｌ‐Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ：ＲＴＰ）フィードバックによって検出可能である。
【０００５】
損失の多いネットワーク通信に関連する内在的な欠点のいくつかを緩和するために、様々なデータリカバリとエラー訂正との特徴が、使用されるデータ符号化規格に組み込まれてきた。例えば、Ｈ２６４／ＡＶＣは最近開発された符号化規格であり、ビデオコンテンツを効果的に表すためのビデオ符号化レイヤ（Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｌａｙｅｒ：ＶＣＬ）と、ビデオのＶＣＬ表示をフォーマットし、特定のトランスポートレイヤによる輸送または記憶媒体に適した方法でヘッダ情報を提供するためのネットワーク抽象レイヤ（Ｎｅｔｗｏｒｋ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ：ＮＡＬ）とを含む。これらの努力にかかわらず、８０２．１１ｘネットワークのような損失の多いネットワーク接続を通した送信信頼性とエラー隠蔽とを改善する必要がある。
【０００６】
送信失敗の確率を下げる、及び／または復号成功の確率を向上させる、及び／または受信機側におけるエラー隠蔽の質を上げるように、ネットワークを通してビデオデータを送信する改善されたシステム及び方法の必要性は、このように、未だ満たされていない。
【発明の概要】
【課題を解決するための手段】
【０００７】
ワイヤレスネットワークのような、損失の多いネットワークを通してデータを送信するためのシステム及び方法がここで開示され、請求される。ある実施形態においては、１つのネットワークを通して符号化されたデータパケットを送信することと、もし符号化されたデータパケットがうまく送信されたならば、肯定確認応答信号（ａｃｋｎｏｗｌｅｄｇｍｅｎｔ ｓｉｇｎａｌ）を受信することと、もし肯定確認応答信号が受信されないならば、再送信試行の数を決定することとを、方法が含み、その再送信試行の数は、符号化されたデータパケット内のデータの種類に少なくとも部分的に基づく。
【０００８】
他の実施形態がここで開示され、請求される。
【図面の簡単な説明】
【０００９】
【図１】図１は、この発明の１つまたはそれ以上の側面の実施形態のための単純化されたシステム概観のある実施形態を表す。
【図２】図２は、ある実施形態に従って本発明のある側面を伝えるための処理を表す。
【図３】図３は、ある実施形態に従って本発明のある側面を伝えるための処理を表す。
【図４】図４は、ある実施形態に従って本発明の別の側面をなお伝えるための処理を表す。
【図５】４個のフィールドからなる１つの実施形態を表す。
【図６】ＩＤＲフレーム６００の別の実施形態を表す。
【発明を実施するための形態】
【００１０】
本発明は、サーバから１つまたはそれ以上のクライアント側のシステムへ、損失の多いネットワークを通して少なくとも部分的にワイヤレスでデータ（例えばビデオデータ）が送信されているシステムに関する。ある実施形態においては、サーバはエンコーダモジュールと送信機とを含み、一方でクライアントはデコーダモジュールと受信機とを含む。
【００１１】
本発明のある側面によれば、サーバによってワイヤレスネットワークを通して送信され、うまく受信されないデータパケットは、特定の回数、再送信可能である。ある実施形態において、再送信試行の数は、失われたパケット内のデータがどのくらい重要であると見なされるかに基づく。つまり、ある実施形態において、再送信試行の数は適応性を持ち得て、より重要であると見なされたパケット（例えばＩＤＲフレームを含むもの）は、より重要でないパケット（例えばＰフレームを含むもの）と比べてより多くの回数、再送信される。ある実施形態において、前述のデータパケットは、Ｈ．２６４／ＡＶＣエンコーダによって符号化されても良く、及び／または８０２．１１ｘワイヤレスネットワーク接続を通して送信され、１つまたはそれ以上のＨ．２６４／ＡＶＣデコーダによって復号されても良い。
【００１２】
本発明の別の側面は、復号成功の確率をクライアント側において改善することである。ある実施形態において、複数の参照フレームを後続の予測操作に使用するよう、対応するエンコーダに対しデコーダに信号送信させることによって、復号成功の確率改善は行われる。これにより、Ｈ．２６４／ＡＶＣシステムの場合において、前のフレーム内（または、Ｂフレームの場合には後来のフレームも）のデータを参照するＰフレームのようなフレームが、複数の参照フレーム内のマクロブロックを参照して、現フレーム内のマクロブロックを判定することが可能になる。
【００１３】
別の実施形態において、元のデータストリームのどのスライスがデコーダにおいて受信されていないか正確に識別することによって、クライアント側における復号成功の確率は改善可能である。ある実施形態において、与えられるパケットに対する肯定確認応答信号はいつ受信されず、パケット再送信試行はいつ全部使用されてしまったかを指摘することによって、クライアント側における復号成功確率の改善は実行可能である。この情報を使用して、エンコーダはその後、これらの失われたスライス／マクロブロックを後来の符号化操作において参照することを中止できる。これによって、クライアント側において後来の復号されたフレームへのエラーの伝播を制限することが可能である。ある実施形態において、この制限は前述の操作と同時に行われる場合がある一方、別の実施形態においては、この制限は後に行われる場合もある。
【００１４】
なお本発明の別の側面は、失われたデータパケット／スライスによって引き起こされるデータの歪みを推定することである。この情報を使用すると、クライアントにおけるエラー隠蔽によって適切に再構築されていると見なされる過去のピクセルが参照され続けることが可能となり、一方で適切に再構築されてはいないデータへの参照は適切に回避されることが可能となる。ある実施形態において、何のエラー隠蔽が使用されたかをクライアントデコーダが正確に知っているとすると、クライアント自体がサーバへ歪みのレベルを示し返すことが可能である。この情報は従ってサーバに返信可能である。しかし、別の実施形態においては、任意の失われたデータパケットに対する、クライアントにおけるエラー隠蔽を推定することによって、受信されたデータのエラーの推定はまたサーバ側で判定可能であって、サーバにおいてまた使用可能である元のデータと再構築されたデータとを比較することによって、歪みが推定されることは従って可能である。
【００１５】
なお本発明の別の側面は、Ｈ．２６４／ＡＶＣのエンコーダ／デコーダシステムの柔軟マクロブロック順序（Ｆｌｅｘｉｂｌｅ Ｍａｃｒｏｂｌｏｃｋ Ｏｒｄｅｒｉｎｇ：ＦＭＯ）機能を使用することによって、クライアントにおけるエラー隠蔽の質を上げることである。つまり、ＩＤＲフレームの全部のマクロブロックが複製なしでｎ個のフィールドに含まれることが可能となるように、まずは各ＩＤＲフレームをｎ個のフィールドに分解することによって、（ピクチャ内の全部の連続するフレームが依存する）ＩＤＲフレームの再構築がより強固となることが可能である。その後、各フィールドはｍ個のスライスにセグメント化されても良い。ある実施形態において、第１のフィールドに代わる全部のｍ個のスライスは最初に送信され、その後に第２のフィールドに代わる全部のｍ個のスライスの送信が続き、そして全部のｎ個のフィールドに代わる全部のｍ個のスライスが送信されてしまうまで、以下同様に続くことが可能である。損失の多いネットワーク環境（例えば８０２．１１ｘ）におけるエラーにはしばしばバースト性があり、エラーの短いバーストは、例えば任意のフィールドに代わる全部のｍ個のスライスを削除するため、各フィールドのスライスを順次送信することは望ましい場合がある。そうであれば、もし異なるフィールド（例えば１と３と４等）に代わるｍ個のスライスが正しく受信されているならば、デコーダ（例えばＨ．２６４／ＡＶＣデコーダ）のエラー隠蔽機能が隣接ピクセルを補間し、欠損ピクセルを推定できる。なぜなら、欠損マクロブロックは使用可能なマクロブロックによって空間的に包囲されているからである。
【００１６】
本発明の前述の側面の全部またはいくつかは、Ｈ．２６４／ＡＶＣのエンコーダ／デコーダシステム及び／または８０２．１１ｘワイヤレスネットワーク接続を使用して実施可能であるいうことが認識されるべきである一方、前述の側面は、他の同様のコーデック及び／または損失の多い通信チャネルを使用しても実施可能であるということがまた同様に認識されるべきである。
【００１７】
ソフトウェアにおいて実施されるとき、本発明の要素は本質的に、必要なタスクを行うためのコードセグメントである。プログラムまたはコードセグメントは処理装置読み取り可能媒体（ｐｒｏｃｅｓｓｏｒ ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）に記憶可能である、または、送信媒体または通信リンクを通るキャリア波において具体化されるコンピュータデータ信号によって送信可能である。
（Ｈ．２６４／ＡＶＣ概観）
【００１８】
Ｈ．２６４／ＡＶＣ規格は、プログレッシブまたはインターレースフレームのいずれか、または同じシーケンス中において共に混合された両方を含むビデオ符号化を支援する。一般的に、ビデオのフレームは２つのインターリーブフィールド――上端及び下端フィールド――を含む。インターレースフレームの２つのフィールドは、フィールド期間で時間的に分離され、２つのフィールドピクチャとして別々に符号化されても良く、または共に１つのフレームピクチャとして符号化されても良い。一方、プログレッシブフレームは単一のフレームピクチャとして符号化される。しかしそれは依然として、時間的に同じ瞬間に２つのフィールドからなると見なされる。
【００１９】
ＶＣＬは、以下でより詳細に記述されるが、ビデオデータのコンテンツを表す。対照的に、ＮＡＬはデータをフォーマットし、トランスポートレイヤによる輸送または記憶媒体に適した方法でヘッダ情報を提供する。全部のデータはＮＡＬユニットに含まれて、その各々は整数個のバイトを含む。ＮＡＬユニットは、パケット指向及びビットストリームシステムの両方における使用のための一般的フォーマットを特定する。
【００２０】
Ｈ．２６４／ＡＶＣ規格のＶＣＬは、ＭＰＥＧ−２のような他の規格と本質的に同様である。要するに、変換符号化と併せて、それは一時的で空間的な予測の混成からなる。ビデオの各ピクチャは、フレームである場合またはフィールドである場合があり、固定サイズのマクロブロックにパーティション化される。そのマクロブロックは、ルーマ（ｌｕｍａ）成分の１６×１６サンプルと、２つのクロマ（ｃｈｒｏｍａ）成分の各々の８×８サンプルとの矩形ピクチャエリアを覆う。マクロブロックの全部のルーマ及びクロマサンプルは、空間的にまたは一時的に予測され、結果の予測残余は変換符号化を使用して送信される。
【００２１】
マクロブロックは、独立して復号可能である任意のイメージの部分を表すスライスにまとめられ、ビットストリームにおけるマクロブロックの送信順序はマクロブロック割り当てマップに依存する。Ｈ．２６４／ＡＶＣ規格は５つの異なるスライス符号化種を支援する。最も単純なものはＩスライス、すなわちイントラスライス（Ｉｎｔｒａ ｓｌｉｃｅ）と呼ばれる。Ｉスライスにおいて、全部のマクロブロックは、ビデオシーケンス内の他のピクチャを参照することなく符号化される。一方、予測符号化されるＰ及びＢスライス（Ｐは予測（ｐｒｅｄｉｃｔｉｖｅ）を表し、Ｂは双予測（ｂｉ‐ｐｒｅｄｉｃｔｉｖｅ）を表す）のマクロブロックにための予測信号を形成するために、先に符号化されるイメージが使用可能である。２つの追加のスライス種はＳＰ（ｓｗｉｔｃｈｉｎｇ Ｐ）とＳＩ（ｓｗｉｔｃｈｉｎｇ Ｉ）とであり、様々なビットレートで符号化されるビットストリーム間の効果的なスイッチングを指定する。
【００２２】
ピクチャ内のマクロブロックを１つまたはいくつかのスライスグループに割り当てるパターンが指定される柔軟マクロブロック順序（ＦＭＯ）と呼ばれる特徴を、Ｈ．２６４／ＡＶＣ規格は支援する。各スライスグループはその後別々に送信可能である。
（システムアーキテクチャ概観）
【００２３】
図１は、本発明の１つまたはそれ以上の側面を実行するためのシステム１００のある実施形態を表す。具体的にはシステム１００は、ソース１００からのビデオコンテンツのキャプチャを含む。ある実施形態において、ビデオコンテンツ１１５は、リアルタイムビデオソースから送信されるリアルタイムコンテンツである場合がある。ビデオコンテンツ１１５は、リアルタイムコンテンツであるか否かにかかわらず、図１の実施形態においてエンコーダ１２０と送信機１３０とを含むサーバ１３５へ、提供可能である。ある実施形態において、エンコーダ１２０はソース１１０からのビデオコンテンツ１１５を処理し、ネットワーク１４０を介して、ある目的地点に符号化されたデータ１２５を提供する。ある実施形態においては、エンコーダ１２０は、前述のＨ．２６４／ＡＶＣ符号化規格に従ってビデオコンテンツ１１５を符号化しても良い。しかし、本発明はＨ．２６４／ＡＶＣ符号化規格以外のコーデックを用いて使用可能であることが同様に認識されるべきである。
【００２４】
図１において示されるように、ひとたび符号化されると、符号化されたデータ１２５は送信機クライアント１４５へ提供される。ある実施形態において送信機１３０は８０２．１１ｘまたは８０２．１５．３ａワイヤレス送信機であるが、送信機１３０は、数多くの他の損失の多いプロトコルに従ってデータを送信しても良いことがまた同様に認識されるべきである。使用されるワイヤレスプロトコルにかかわらず、符号化されたデータ１２５はネットワーク１４０に提供され、ネットワーク１４０を通して送信可能である。ある実施形態において、エンコーダ１２０は、前述のＨ．２６４／ＡＶＣ符号化規格に従ってビデオコンテンツ１１５を符号化できる。しかし、Ｈ．２６４／ＡＶＣ符号化規格以外の同様のコーデックと、８０２．１１ｘ／８０２．１５．３ａワイヤレスネットワーク以外の損失の多いネットワークとを用いて、本発明は使用可能であるということが同様に認識されるべきである。
【００２５】
図１の参照を続けると、クライアント１４５は受信機１５０とデコーダ１５５とを含む。符号化されたデータ１２５は、ネットワーク１４０（例えばインターネット）と通信中の受信機１４５によって受信可能である。すると受信機１５０は符号化されたデータ１２５をデコーダ１５０へ提供する。別の実施形態においては、符号化されたデータ１２５はクライアント側の複数の装置（示されず）によって受信され、復号されても良い。図１において示されるように、エンコーダ１２０によって使用される符号化規格（例えばＨ．２６４／ＡＶＣ）に依存して、デコーダ１５５はその後、符号化されたデータ１２５の特別な復号操作を行って、接続されるディスプレイ１６５へ復号されたビデオコンテンツ１６０を提供することが可能である。
【００２６】
サーバ１３５とクライアント１４５とは、図１に表される以外の数多くの構成が可能であるということが認識されるべきである。例えば、エンコーダ１２０と送信機１３０とのいずれかまたは両方は、サーバ１３５から分離されても良い。同様に、デコーダ１５５と受信機１５０とのいずれかまたは両方は、クライアント１４５に集積されなくても良い。
【００２７】
示されてはいないが、計算とデータの一時的な記憶のためのレジスタの収集と命令とを行うための数値演算装置（ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ：ＡＬＵ）を含むことが可能である中央処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ：ＣＰＵ）と、コンピュータシステムの制御操作のための制御装置とのような他の成分を、サーバ１３５及び／またはクライアント１４５は含むことが可能であるということが同様に認識されるべきである。ある実施形態において、ＣＰＵは、ｘ８６、またはインテル（登録商標）社（ＩｎｔｅｌTMＣｏｒｐｏｒａｔｉｏｎ）によって販売されるＰｅｎｔｉｕｍTM級マイクロプロセッサ、またはＡＭＤTMによって販売されるマイクロプロセッサ、またはサイリックス（登録商標）社（ＣｙｒｉｘTMＣｏｒｐ．）よって販売される６ｘ８６ＭＸマイクロプロセッサのどの１つでも良い。加えて、ＭＩＰＳ、ＩＢＭ、モトローラ（Ｍｏｔｏｒｏｌａ）、ＮＥＣ、サイリックス、ＡＭＤ、ネクスジェン（Ｎｅｘｇｅｎ）他からのものを含む様々な他のプロセッサのいずれも使用可能である。さらに、このようなＣＰＵのいずれもマイクロプロセッサに限定される必要はなく、マイクロコントローラ、デジタル信号プロセッサ、縮小命令セットコンピュータ（ｒｅｄｕｃｅｄ ｉｎｓｔｒｕｃｔｉｏｎ ｓｅｔ ｃｏｍｐｕｔｅｒｓ：ＲＩＳＣ）、アプリケーション固有の集積回路、そしてそれらの類似のもののような、他の形態をとっても良い。
【００２８】
サーバ１３５及び／またはクライアント１４５が含むことができる他の成分は、ランダムアクセスメモリと、不揮発性記憶装置（例えばハードディスク、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、テープ、高密度フロッピー（登録商標）、高容量リムーバブルメディア、低容量リムーバブルメディア、固体記憶装置等、そしてそれらの組み合わせ）とである。サーバ１３５及び／またはクライアント１４５は、またネットワークインターフェース（例えばネットワークインターフェースカード、モデムインターフェース、統合サービスデジタル通信網等）と、ユーザ入力装置（例えば、命令と交流し、提供することをユーザに可能にするキーボード、マウス、ジョイスティック、そしてその類似のもの）とを含んでも良い。
【００２９】
サーバ１３５及び／またはクライアント１４５は、サーバ１３５及び／またはクライアントの作動と資源の割り当てとを制御するための、システムＢＩＯＳのようなシステムファームウェアとオペレーティングシステム（例えばＤＯＳ、ウインドウズ（Ｗｉｎｄｏｗｓ（登録商標））、ユニックス（Ｕｎｉｘ（登録商標））、リナックス（登録商標）（Ｌｉｎｕｘ（登録商標））、ゼニックス（Ｘｅｎｉｘ）等）とを含んでも良いということがさらに認識されるべきである。
（送信失敗の確率低下）
【００３０】
上で言及したように、本発明のある側面は送信失敗の確率を低下可能とすることである。そのために、図２は本発明のある実施形態に従って、処理２００を示し、送信失敗の確率がどのようにして低下可能となるかを表す。リアルタイムワイヤレス送信について言えば、全部のデータパケットの送信成功を保障することは必ずしも実行可能とは限らない。具体的には、過剰な冗長送信が、許容できない待ち時間につながる場合がある。そういうことで、いくつかのデータパケットは他よりも重要であると見なされる場合がある。ゆえに、再送信試行の数は、問題のパケットの重要性の関数となり得る。例えば、瞬時デコーダリフレッシュ（Ｉｎｓｔａｎｔａｎｅｏｕｓ Ｄｅｃｏｄｅｒ Ｒｅｆｒｅｓｈ：ＩＤＲ）フレームを含むパケットは、予測（ｐｒｅｄｉｃｔｉｖｅ）フレーム、すなわちＰフレームを含むもののような、より重要でないパケットと比べてより多くの回数、再送信されることができる。そのために、処理２００は、データパケットの送信についてのブロック２１０から始まる。その後ブロック２２０にて、パケットが受信されたかどうかに関する判定が行われる。ある実施形態において、この判定は、目的地点の受信機（例えばクライアント１４５）がソース（例えばサーバ１３５）へＡＣＫ信号を返したかどうかに基づく場合がある。しかし、パケット配信成功はまた他の手段を使用して判定されても良いことが同様に認識されるべきである。
【００３１】
もし問題のパケットが実際に受信されたとブロック２２０で判定されるならば、処理２００は単純にブロック２３０へ移行し、次のデータパケットが処理される。一方、パケットが適切に受信されなかったと判定される場合には、処理２００はブロック２４０へ続き、そのパケットに対して再送信が何回試行されるべきかに関する決定が実行可能である。ある実施形態において、再送信試行の数は、そのパケット内に含まれるデータの重要性に基づく。別の実施形態においては、再送信が実行されて発生する全部のレベルにおいて、再送信の数は適応可能となることができる。例えば、再送信の数は、８０２．１１ｘＭＡＣレイヤに適応可能となっても良く、信頼できるまたは半分信頼できるＲＴＰ再送信の形が実施されている場合には、同様にＲＴＰレイヤに適応可能となっても良い。
【００３２】
ひとたびパケットの再送信の数が決定されてしまうと、処理２００はブロック２５０へ続き、そのパケットが再送信されるべきかどうかが判定される。もし再送信試行の数が零に等しければ、そのパケットは再送信されず、処理２００は終了する。一方、もし再送信試行の数が零より多ければ、処理２００はブロック２６０へ続き、パケットが再送信され、その後残りの再送信試行の数が１減る（ブロック２７０）。ひとたび再送信されると、その後ブロック２８０にて、再送信されたパケットが今回で受信されたかどうかに関する判定が行われなければならない。もし受信されたならば、処理２００は単純にブロック２３０へ移行し、次のデータパケットが処理される。もし受信されていなければ、処理２００はブロック２５０に戻り、パケットが再送信されるべきかどうかが判定される（すなわち、再送信試行の数が零と等しいか否かを判定する）。
（復号成功の確率上昇）
【００３３】
上で言及したように、本発明の別の側面は、損失の多い送信のクライアント側における復号成功の確率を上げることである。そのために、損失の多いネットワーク（例えばネットワーク１４０）を通して送信されるビデオコンテンツの復号を改善するための処理３００のある実施形態を、図３は示す。具体的には、処理３００は、送信失敗の数が増加しているかどうかの判定から始まる。例えばクライアント側の装置（例えばクライアント１４５）によって送信されるＡＣＫの数の減少を検出することによって、送信失敗の数の増加の判定は行われることが可能である。ある実施形態において、対するＡＣＫの数を比較するために、既定の閾値が使用可能である。ひとたびＡＣＫの数（または任意の時間毎にＡＣＫが受信されるレート）が、既定の閾値を下回ると、処理３００は、ブロック３１０及び３２０及び３３５の内１つまたはそれ以上へ続く。つまり、処理３００の部分は同時にまたは連続的に実行可能である。例えば、ブロック３１０〜３１５を含む処理３００の部分は、ブロック３２０〜３３０及び／またはブロック３３５〜３４５を参照して以下に説明される操作と同時に実行できる。
【００３４】
ひとたびＡＣＫの数（またはＡＣＫの受信レート）が、既定の閾値を下回ると、クライアントすなわちデコーダ側は、エンコーダへ、そのエンコーダが予測の目的で複数の参照フレームを使用すべきであると信号を送り返す。例えば、Ｈ．２６４／ＡＶＣエンコーダの場合、前のフレーム（またはＢフレームの場合には後来のフレームも）内のデータを参照するＰフレームは、現フレーム内のマクロブロックを判定するために、複数の参照フレーム内のマクロブロックを参照する。ゆえに、損失の多い送信エラーが原因で参照フレームの１つが欠損する場合において、他の参照フレームまでは失われていないと仮定すると、現フレームはまだうまく再構築される可能性がある。
【００３５】
このように、複数の参照フレームを使用する（ブロック３１５）ことによって、予想される後来のフレームの破損につながるカスケーディング効果（ｃａｓｃａｄｉｎｇ ｅｆｆｅｃｔ）を、失われたフレームが引き起こす確率は、効果的に低下可能である。ブロック３１５から通じる進行破線によって示されるように、ブロック３１０〜３１５の操作は、ブロック３２０〜３３０及び３３５〜３４５を参照して以下に記述される操作と同時にまたは連続的に実行可能である。
【００３６】
連続的に行われるか同時に行われるかにかかわらず、ブロック３２０において、元のビデオストリームのどのスライスがデコーダで受信されていないのかを、サーバ側（例えばサーバ１３５）は正確に識別する。ある実施形態においては、８０２．１１ｘＭＡＣレイヤにおいてそのパケットに対してＡＣＫ信号は受信されてはいないことから、サーバはどのデータパケットが失われているかを認知している、またはサーバはＲＴＰアプリケーションレイヤにおいてどのＲＴＰパケットが失われているかを認知しているので、この情報は使用可能である。ひとたび欠損スライスが識別されてしまうと、処理３００はブロック３２５へ続くことが可能であり、どのスライス（ゆえにどのマクロブロック）がデコーダによって受信されていないかを、エンコーダは通知されることが可能である。この情報を使用して、（ある実施形態においてＨ２．６４／ＡＶＣエンコーダである）エンコーダは、後来のＰ及びＢフレーム内のこれらの失われたスライス／マクロブロックを参照することを中止する（ブロック３３０）。別の実施形態においては、エンコーダは、必要ならばまた追加のＩＤＲフレームを生成しても良い。
【００３７】
処理３００の前述の操作と同時にまたは連続的にブロック３３５において、欠損パケットによって引き起こされる歪みのレベルが、サーバによって推定可能である。全部の失われたパケットが同様にビデオを劣化させるわけではなく、特に、多くのデコーダ（例えばＨ２６４デコーダ）はエラー隠蔽を使用するため、この歪みレベル推定可能性は重要である場合がある。ある実施形態においては、失われたパケットによって引き起こされるクライアントのビデオの歪みを、クライアント自体が推定できる。デコーダが、知的財産権を有する場合もあり得るエラー隠蔽をどのように実施してきたかを、自身で正確に認知するため、このクライアント自身による推定は好ましい場合がある。この場合、歪みのレベルはサーバへ返信される（ブロック３４０）。
【００３８】
代替として、クライアントとサーバ間の通信のこのバックチャネルは信用できない場合がある。その場合、その任意の失われたスライス／パケットに対するクライアントにおけるエラー隠蔽を推定することによって、最終のビデオのエラーの推定はまたサーバで判定されても良い。サーバでも同様に使用可能である元のビデオと再構築されたビデオとを比較することによって、歪みは推定可能である。歪みがクライアント側で推定されたか、サーバ側で推定されたかにかかわらず、この情報はその後エンコーダによって使用され、クライアントにおけるエラー隠蔽によって適切に再構築されたと見なされる過去のピクセルのみ参照可能となる（ブロック３４５）。
【００３９】
リアルタイムビデオコンテンツに加えて、図３の処理３００は、あらかじめ記憶されるストリームに対し、（ＰＶＲまたはＩＳＰヘッドエンドのような）サーバ側でもまた実施可能である。この場合、同じ符号化されたストリームのバージョンがいくつかあらかじめ記憶可能となり、それにより、符号化されたデータのこのような複数のバージョンをオンザフライで作成する待ち時間が減少可能となる。コンテンツがリアルタイムで符号化されている他の場合において、待ち時間によって重大な影響を受けやすいアプリケーションについては、複数の符号化されたストリーム（例えばＨ．２６４／ＡＶＣ）の間でスイッチングを可能にして、上に説明されたような特定の失われたスライスのいずれかへの依存性を制限することによって、それらを同時に生成することが好ましい場合がある。
（エラー隠蔽の質の向上）
【００４０】
上で言及したように、本発明の別の側面は、損失の多い送信のクライアント側におけるエラー隠蔽の質を上げることである。そのために、エラー隠蔽を使用して、欠損マクロブロックによって引き起こされるビデオコンテントの歪みを減らす処理４００のある実施形態を、図４は示す。Ｈ．２６４／ＡＶＣエンコーダの場合、柔軟マクロブロック順序（ＦＭＯ）が使用可能である。図４の処理４００を使用すると、（ピクチャ内の全部の連続するフレームが依存する）ＩＤＲフレームの再構築が、より強固となる場合がある。具体的には、処理４００は、ブロック４１０において、各ＩＤＲフレームをｎ個のフィールドに分解することから始まる。図５を参照して以下に示されるように、ｐ個のマクロブロックによって他のマクロブロックから空間的に分離されるマクロブロックを、各フィールドは含むことができる。ゆえに、ＩＤＲフレームの全部のマクロブロックは、複製なしで、ｎ個のフィールドに含まれることができる。その後ブロック４２０において、ＮＡＬによって、各フィールドはｍ個のスライスにセグメント化されることが可能であり、その場合ワイヤレスネットワーク（例えば８０２．１１ｘ）リンクレイヤによって、サイズ制限が課される。
【００４１】
ひとたびフィールドがｍ個のスライスにセグメント化されてしまうと、処理４００はブロック４３０に続くことが可能であり、１番目のフィールドに代わる全部のｍ個のスライスが最初に送信可能であり、その後に２番目のフィールドに代わる全部のｍ個のスライスの送信が続き、全部のｎ個のフィールドに代わる全部のｍ個のスライスが送信されてしまうまで以下同様に続く。損失の多いネットワーク（例えば８０２．１１ｘ）を通した送信に、この送信形態は特に有用である場合があって、そのようなネットワークにおいては、しばしばエラーがバースト性をもち、エラーの短いバーストが、任意のフィールドに代わる全部のｍ個のスライスを消去する。しかし、異なるフィールド（例えば１と３と４等）に代わるｍ個のスライスが正しく受信されている場合には、使用可能なマクロブロックに欠損マクロブロックが空間的に隣接している、または包囲されていると仮定すると、デコーダ（例えばＨ．２６４／ＡＶＣデコーダ）のエラー隠蔽機能は隣接ピクセルを補間し、欠損ピクセルを推定可能であろう。複製データを送信して、失われたパケットまたはスライスを補う必要性を、このアプローチは回避し、ゆえにその必要な帯域幅はより小さい。別の実施形態においては、単一のマクロブロックがｎ個のマクロブロックによって分離される代わりに、単一のマクロブロックはそれ自体その元のマクロブロックの周りのマクロブロックの組を含むまで拡張されても良い。
【００４２】
別の実施形態において、ネットワークの他のステージにて重大な混雑が発生するならば、図４の符号化処理４００はまたバッファ管理とストリーミングスタックとを援助して、データのどのパケットがドロップ可能であるかを、ワイヤレス送信前に（またはワイヤレス受信の後に）判定することが可能である。元のストリーム内のパケットをどれでもランダムにドロップすることと比べると、フレームのフィールドの１つを含むネットワークパケットをドロップすることによって、受信機においてビデオ復号のより良い質が得られる結果となる場合がある。空間的多重化ＭＩＭＯワイヤレス技術が使用される特定のアプリケーションに対して、動作をさらに改善するために、空間的に別々のチャネル上で各フィールドを任意に送信することが可能であることがさらに認識されるべきである。
【００４３】
前述の処理４００はＩＤＲフレームについて記述されたが、使用可能な帯域幅と計算資源（ｃｏｍｐｕｔａｔｉｏｎａｌ ｒｅｓｏｕｒｃｅｓ）とが許す限り、空間的なイントラフレームデータを含むどんな種類のデータフレームを用いても、この処理４００は使用可能であるということがさらに認識されるであろう。
【００４４】
ここで図５を参照すると、４個のフィールドからなる１つの実施形態が表されており、ｐ＝１のマクロブロックによって、いずれか１つのフィールドの個別のマクロブロックは、水平方向及び垂直方向の両方において、各々から空間的に分離される。図５に示されるように、例えば、フィールド＃３は、「３」とラベルされる全部の個別のマクロブロックからなる。この方法において、フィールド＃３は複数のスライス／パケットで送信され、デコーダ側のエラー隠蔽機能を改善することによって、バースト性エラーの影響を減らすことが可能である。
【００４５】
図６はＩＤＲフレーム６００の別の実施形態を表す。しかし、図６の実施形態においては、ＩＤＲフレーム６００は複数の「スーパーマクロブロック（ｓｕｐｅｒ‐ｍａｃｒｏｂｌｏｃｋｓ）」からなる。この実施形態において、スーパーマクロブロックは４個の別々のマクロブロックで構成され、それらは皆、同じフィールドに対するデータを含む。このように、例えば＃１とラベルされる全部のスーパーマクロブロックはフィールド＃１の部分と見なされ、１つまたはそれ以上のスライスとして順に送信される。その後、（対応して、＃２とラベルされるスーパーマクロブロックからなる）フィールド＃２についても同様に行われ、その後フィールド＃３以下同様である。図５のマクロブロックベースのアルゴリズムと比較されると、図６のスーパーマクロブロックアルゴリズムは符号化効率を上げる傾向があるだろうが、しかし送信中にフィールドが失われた場合、デコーダにおける再構築の正確性は落ちるであろう。
【００４６】
以上、本発明について、さまざまな実施形態について説明してきたが、本発明は、さらなる変更が可能であることを了解されたい。本出願は、本発明のさまざまな変形例、用途、適応例を包含すること、および、本発明の原理に従う限り、本発明の属する技術分野における既知のおよび慣習的な実施範囲における本発明の開示内容からの逸脱を含むことを意図してなされたものである。
【特許請求の範囲】
【請求項１】
ネットワークを通して、符号化されたデータパケットを送信することと、
肯定確認信号を受信しなかったことと、ここで、当該受信しなかったことは、前記符号化されたデータパケットがうまく送信されなかったことを示し、
再送信試行の数を決定することと、ここで、前記再送信試行の数は、前記符号化されたデータパケット内のデータの種類に少なくとも部分的に基づくことと、
送信失敗の数が既定の閾値を超えた場合はそのことを判定することと、
前記既定の閾値に従って、送信失敗を補うようエンコーダを選択的に設定すること、
を含み、
送信失敗の数が前記既定の閾値を超えることの前記判定は、送信されている肯定確認応答信号の数の減少を検出することを含むものであり、
前記選択的に設定することは、
前記ネットワークを通して送信された複数の失われたデータパケットの失敗した受信によって引き起こされる歪みレベルを推定することと、
前記複数の失われたデータパケットを参照することを回避するために、前記歪みレベルを使用して、追加のデータを符号化することと、
を含むものである、方法。
【請求項２】
前記符号化されたデータパケットは、Ｈ．２６４／ＡＶＣ符号化規格に従って符号化される、請求項１の方法。
【請求項３】
前記ネットワークは損失の多いワイヤレスネットワークである、請求項１の方法。
【請求項４】
前記符号化されたデータパケット内の前記データの種類が瞬時デコーダリフレッシュ（ＩＤＲ）フレームデータであると、前記再送信試行の数は増加する、請求項１の方法。
【請求項５】
前記選択的に設定することは、複数の参照フレームが符号化予測に使用されるべきであることを信号送信することを含む、請求項１の方法。
【請求項６】
ネットワークと、
前記ネットワークに結合されるクライアントと、前記クライアントはデコーダと受信機とを含み、
前記ネットワークに結合されるサーバと、前記サーバはエンコーダと送信機とを含み、
を含むシステムであって、前記サーバは、
前記ネットワークを通して前記クライアントへ符号化されたデータパケットを送信し、
肯定確認応答信号を受信せず、ここで前記受信しないことは、前記符号化されたデータパケットが前記クライアントへうまく送信されなかったことを示し、
再送信試行の数を決定し、ここで前記再送信試行の数は、前記符号化されたデータパケット内のデータの種類に少なくとも部分的に基づき、
送信失敗の数が既定の閾値を超えた場合はそのことを判定し、
前記既定の閾値に従って、送信失敗を補うようエンコーダを選択的に設定する、
よう構成されており、
送信失敗の数が既定の閾値を超えることの前記判定は、送信される肯定確認応答信号の数の減少を検出することを含むものであり、
前記選択的な設定は、
前記ネットワークを通して送信された複数の失われたデータパケットの失敗した受信によって引き起こされる歪みレベルを推定することと、
前記ネットワークを通して送信された前記複数の失われたデータパケットを参照することを回避するために、前記歪みレベルを使用して、追加のデータを符号化することと、
を含ものである、システム。
【請求項７】
前記符号化されたデータパケットは、Ｈ．２６４／ＡＶＣ符号化規格に従って符号化される、請求項６のシステム。
【請求項８】
前記ネットワークは損失の多いワイヤレスネットワークである、請求項６のシステム。
【請求項９】
前記符号化されたデータパケット内の前記データの種類が瞬時デコーダリフレッシュ（ＩＤＲ）フレームデータであると、前記再送信試行の数は増加する、請求項６のシステム。
【請求項１０】
前記選択的な設定は、複数の参照フレームが符号化予測に使用されるべきであることを前記サーバに信号送信することを含む、請求項６のシステム。
【請求項１１】
ワイヤレスネットワークを通して複数の符号化されたデータパケットを送信することと、
うまく送信されたとき、前記複数の符号化されたデータパケットの選択に対する肯定確認応答信号を受信しないことと、ここで前記受信しないことは、複数の符号化されたデータパケットの選択がうまく送信されなかったことを示し、
送信失敗の数が既定の閾値を超えることを判定することと、
複数の参照フレームが符号化予測のために使用されるべきであることを信号送信することとを含み、
送信失敗の数が既定の閾値を超えるかどうかを判定することは、送信されている肯定確認応答信号の数の減少を検出することを含み、
さらに、
前記うまく送信されなかった符号化されたデータパケットの選択の失敗した受信によって引き起こされる歪みレベルを推定することと、
前記うまく送信されなかった符号化されたデータパケットの選択を参照することを回避するために、前記歪みレベルを使用して、追加のデータを符号化することと、
を含む方法。
【請求項１２】
前記複数の符号化されたデータパケットは、Ｈ．２６４／ＡＶＣ符号化規格に従って符号化される、請求項１１の方法。
【請求項１３】
前記ワイヤレスネットワークは損失の多いワイヤレスネットワークである、請求項１１の方法。
【請求項１４】
うまく送信されなかった符号化されたデータパケットの選択された特定の一つについての再送信試行の数を決定することを含み、前記再送信試行の数は前記符号化されたデータパケット内のデータの種類に少なくとも部分的に基づく、請求項１１の方法。
【請求項１５】
前記特定の符号化されたデータパケット内の前記データの種類が瞬時デコーダリフレッシュ（ＩＤＲ）フレームデータであると、前記再送信試行の数は増加する、請求項１１の方法。
【請求項１６】
前記複数の参照フレームのそれぞれが、デコーダのエラー隠蔽機能の品質が改善するよう構成された複数のフィールドに分割される、請求項１１の方法。
【請求項１７】
前記選択的な設定は、追加の符号化されたデータに対するフレームを、デコーダのエラー隠蔽機能の品質が改善するよう構成された複数のフィールドに分割することを含む、請求項６のシステム。
【請求項１８】
前記選択的な設定は、追加の符号化されたデータに対するフレームを、デコーダのエラー隠蔽機能の品質が改善するよう構成された複数のフィールドに分割することを含む、請求項１の方法。
【請求項１】
ネットワークを通して、符号化されたデータパケットを送信することと、
肯定確認信号を受信しなかったことと、ここで、当該受信しなかったことは、前記符号化されたデータパケットがうまく送信されなかったことを示し、
再送信試行の数を決定することと、ここで、前記再送信試行の数は、前記符号化されたデータパケット内のデータの種類に少なくとも部分的に基づくことと、
送信失敗の数が既定の閾値を超えた場合はそのことを判定することと、
前記既定の閾値に従って、送信失敗を補うようエンコーダを選択的に設定すること、
を含み、
送信失敗の数が前記既定の閾値を超えることの前記判定は、送信されている肯定確認応答信号の数の減少を検出することを含むものであり、
前記選択的に設定することは、
前記ネットワークを通して送信された複数の失われたデータパケットの失敗した受信によって引き起こされる歪みレベルを推定することと、
前記複数の失われたデータパケットを参照することを回避するために、前記歪みレベルを使用して、追加のデータを符号化することと、
を含むものである、方法。
【請求項２】
前記符号化されたデータパケットは、Ｈ．２６４／ＡＶＣ符号化規格に従って符号化される、請求項１の方法。
【請求項３】
前記ネットワークは損失の多いワイヤレスネットワークである、請求項１の方法。
【請求項４】
前記符号化されたデータパケット内の前記データの種類が瞬時デコーダリフレッシュ（ＩＤＲ）フレームデータであると、前記再送信試行の数は増加する、請求項１の方法。
【請求項５】
前記選択的に設定することは、複数の参照フレームが符号化予測に使用されるべきであることを信号送信することを含む、請求項１の方法。
【請求項６】
ネットワークと、
前記ネットワークに結合されるクライアントと、前記クライアントはデコーダと受信機とを含み、
前記ネットワークに結合されるサーバと、前記サーバはエンコーダと送信機とを含み、
を含むシステムであって、前記サーバは、
前記ネットワークを通して前記クライアントへ符号化されたデータパケットを送信し、
肯定確認応答信号を受信せず、ここで前記受信しないことは、前記符号化されたデータパケットが前記クライアントへうまく送信されなかったことを示し、
再送信試行の数を決定し、ここで前記再送信試行の数は、前記符号化されたデータパケット内のデータの種類に少なくとも部分的に基づき、
送信失敗の数が既定の閾値を超えた場合はそのことを判定し、
前記既定の閾値に従って、送信失敗を補うようエンコーダを選択的に設定する、
よう構成されており、
送信失敗の数が既定の閾値を超えることの前記判定は、送信される肯定確認応答信号の数の減少を検出することを含むものであり、
前記選択的な設定は、
前記ネットワークを通して送信された複数の失われたデータパケットの失敗した受信によって引き起こされる歪みレベルを推定することと、
前記ネットワークを通して送信された前記複数の失われたデータパケットを参照することを回避するために、前記歪みレベルを使用して、追加のデータを符号化することと、
を含ものである、システム。
【請求項７】
前記符号化されたデータパケットは、Ｈ．２６４／ＡＶＣ符号化規格に従って符号化される、請求項６のシステム。
【請求項８】
前記ネットワークは損失の多いワイヤレスネットワークである、請求項６のシステム。
【請求項９】
前記符号化されたデータパケット内の前記データの種類が瞬時デコーダリフレッシュ（ＩＤＲ）フレームデータであると、前記再送信試行の数は増加する、請求項６のシステム。
【請求項１０】
前記選択的な設定は、複数の参照フレームが符号化予測に使用されるべきであることを前記サーバに信号送信することを含む、請求項６のシステム。
【請求項１１】
ワイヤレスネットワークを通して複数の符号化されたデータパケットを送信することと、
うまく送信されたとき、前記複数の符号化されたデータパケットの選択に対する肯定確認応答信号を受信しないことと、ここで前記受信しないことは、複数の符号化されたデータパケットの選択がうまく送信されなかったことを示し、
送信失敗の数が既定の閾値を超えることを判定することと、
複数の参照フレームが符号化予測のために使用されるべきであることを信号送信することとを含み、
送信失敗の数が既定の閾値を超えるかどうかを判定することは、送信されている肯定確認応答信号の数の減少を検出することを含み、
さらに、
前記うまく送信されなかった符号化されたデータパケットの選択の失敗した受信によって引き起こされる歪みレベルを推定することと、
前記うまく送信されなかった符号化されたデータパケットの選択を参照することを回避するために、前記歪みレベルを使用して、追加のデータを符号化することと、
を含む方法。
【請求項１２】
前記複数の符号化されたデータパケットは、Ｈ．２６４／ＡＶＣ符号化規格に従って符号化される、請求項１１の方法。
【請求項１３】
前記ワイヤレスネットワークは損失の多いワイヤレスネットワークである、請求項１１の方法。
【請求項１４】
うまく送信されなかった符号化されたデータパケットの選択された特定の一つについての再送信試行の数を決定することを含み、前記再送信試行の数は前記符号化されたデータパケット内のデータの種類に少なくとも部分的に基づく、請求項１１の方法。
【請求項１５】
前記特定の符号化されたデータパケット内の前記データの種類が瞬時デコーダリフレッシュ（ＩＤＲ）フレームデータであると、前記再送信試行の数は増加する、請求項１１の方法。
【請求項１６】
前記複数の参照フレームのそれぞれが、デコーダのエラー隠蔽機能の品質が改善するよう構成された複数のフィールドに分割される、請求項１１の方法。
【請求項１７】
前記選択的な設定は、追加の符号化されたデータに対するフレームを、デコーダのエラー隠蔽機能の品質が改善するよう構成された複数のフィールドに分割することを含む、請求項６のシステム。
【請求項１８】
前記選択的な設定は、追加の符号化されたデータに対するフレームを、デコーダのエラー隠蔽機能の品質が改善するよう構成された複数のフィールドに分割することを含む、請求項１の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１３−７０４３６（Ｐ２０１３−７０４３６Ａ）
【公開日】平成２５年４月１８日（２０１３．４．１８）
【国際特許分類】
【出願番号】特願２０１３−２７９６（Ｐ２０１３−２７９６）
【出願日】平成２５年１月１０日（２０１３．１．１０）
【分割の表示】特願２００８−５２５０６２（Ｐ２００８−５２５０６２）の分割
【原出願日】平成１８年７月２８日（２００６．７．２８）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【出願人】（５９３１８１６３８）ソニー エレクトロニクス インク (371)
【Ｆターム（参考）】
【公開日】平成２５年４月１８日（２０１３．４．１８）
【国際特許分類】
【出願日】平成２５年１月１０日（２０１３．１．１０）
【分割の表示】特願２００８−５２５０６２（Ｐ２００８−５２５０６２）の分割
【原出願日】平成１８年７月２８日（２００６．７．２８）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【出願人】（５９３１８１６３８）ソニー エレクトロニクス インク (371)
【Ｆターム（参考）】
[ Back to top ]