(57)【特許請求の範囲】
【請求項１】
計算システムにより実行されるコンピュータ実施の方法であって、前記計算システムはコンピュータ実行可能な命令を含むメモリを含み、前記命令は前記計算システムの一以上のプロセッサにより実行されると、不完全なビデオデータを復号する方法を実行し、前記コンピュータ実施の方法は、
ビデオデータに含まれるフレームの少なくとも１つのピースにアクセスすることであって、前記フレームはそれぞれが個別に復号可能な複数のフレームピースを含む、ことと、
前記フレームの少なくとも１つの追加フレームピースを受信されるのを待つ間に、アクセスされた少なくとも１つのフレームピースを復号することと、
前記フレームの少なくとも１つの追加フレームピースが受信されていないと判断することにより、前記フレームが不完全であると判断することと、
前記フレームが不完全であるとの判断及び指定された最小閾値数のフレームピースが受信されたとの判断に応じて、
少なくとも１つの前のフレームに関連するフレームデータの少なくとも一部を用いて、前記不完全なフレームの一以上のフレームピースを合成することと、
アクセスされ復号された少なくとも１つのフレームピースと、前記合成された一以上のフレームピースとを組み合わせることにより、前記不完全なフレームを完成させることと、
前記不完全なフレームが不完全であるとの判断及び前記指定された最小閾値数のフレームピースが受信されていないとの判断に応じて、
フレーム置換データが送信されるべきことを示す通知を生成することと、
生成された通知を第２の計算システムに送信することと
を含む、コンピュータ実施の方法。
【請求項２】
インクリメント状に増加するタイムスタンプを用いて、フレームとフレームピースが別々にトラッキングされる、請求項１に記載のコンピュータ実施の方法。
【請求項３】
前記不完全なフレームの前方エラー訂正データを待つことと、前記前方エラー訂正データを待っている間に、前記不完全なフレームの他のフレームピースを復号し続けることとを含む、
請求項１に記載のコンピュータ実施の方法。
【請求項４】
前記不完全なフレームの前方エラー訂正データを受け取ることと、
前記前方エラー訂正データが対応する前記不完全なフレームのフレームピースを復号することとをさらに含む、
請求項３に記載のコンピュータ実施の方法。
【請求項５】
計算システムに請求項１乃至４いずれか一項に記載のコンピュータ実施の方法を実行させるコンピュータプログラム。
【発明の詳細な説明】
【背景技術】
【０００１】
世界中で日常的に、インターネットその他のネットワークによりコンシューマに、ビデオデータが送信されている。ビデオデータは一般的にビデオフレームデータパケットロスを許容する、又は補償するプロトコルを用いて送信される。例えば、Ｈ．２６４フォーマットを用いて符号化されたビデオフレームは、異なる複数のピースすなわち「スライス」を用いて送信されてもよく、各スライスは複数のフレームデータパケットを含んでもよい。これらのパケットは、伝送中に失われたり、様々な理由で遅延したりすることがある。あるフレームのフレームデータがある時間にわたり受信されないままである場合、そのフレームは破棄され、視覚的忠実性が損なわれ、ビデオコンシューマにより知覚されることがある。
【発明の概要】
【０００２】
ここに説明する実施形態は、不完全なビデオデータの復号に関する。一実施形態では、コンピュータシステムはフレームのピース（ａ  ｐｉｅｃｅ  ｏｆ  ａ  ｆｒａｍｅ）（例えば、ビデオフレーム）を受信する。フレームは、複数のフレームピース又は「スライス」を含み、各フレームピースは個別に復号可能であるように符号化される。コンピュータシステムは、少なくとも１つの追加フレームピースを受信するのを待ちつつ、受信したフレームピースを復号する。次いで、フレームが不完全であることを示す状態が発生すると、コンピュータシステムはフレームピースを合成して、まだ受信されていない追加フレームピースを置き換える。
【０００３】
他の一実施形態において、フレームのピースの受信に応じて、コンピュータシステムは、他のフレームピースが受信されるのを待ちつつ、受信したフレームピースを復号する。コンピュータシステムは、フレームが不完全であり、そのフレームには少なくとも１つのまだ受信される予定の追加フレームピースがあることを示す状態の発生を検出する。次いで、その発生の検出に応じて、コンピュータシステムは、まだ受信される予定の追加フレームを置き換えるフレームピースを合成する。
【０００４】
他の一実施形態において、コンピュータシステムは、複数のフレームピースを含むフレームの１つのフレームピースにアクセスする。各フレームピースは個別に復号可能である。コンピュータシステムは、追加フレームピースが受信されるのを待ちつつ、アクセスしたフレームピースを復号する。コンピュータシステムは、少なくとも１つの追加フレームピースがまだ受信される予定であると判断し、その判断に応じて、前のフレームに関連するフレームデータを用いてフレームピースを合成する。
【０００５】
本欄では、発明の詳細な説明で詳しく説明するコンセプトの一部を選んで、簡単に説明する。本欄は、特許を請求する主題の重要な特徴や本質的な特徴を特定するものではなく、特許を請求する主題の範囲を決定するのを助けるものでもない。
【０００６】
その他のフィーチャと利点は、以下の説明に記載され、部分的に本技術分野の当業者には説明により明らかであり、又はここでの教示の実施により学習されてもよい。ここに説明の実施形態のフィーチャと利点は、添付した特許請求の範囲に指摘される機器及び組み合わせにより実現され取得されてもよい。ここに説明の実施形態のフィーチャは、以下の説明及び添付した特許請求の範囲からより完全に明らかになるだろう。
【図面の簡単な説明】
【０００７】
ここに説明する上記その他のフィーチャ（ｆｅａｔｕｒｅｓ）をさらに明確にするため、添付の図面を参照して、より具体的な説明をする。言うまでもなく、これらの図面はここに説明する実施形態の例を示しているだけであり、実施形態の範囲を限定するものであると考えてはならない。添付した図面を用いて、実施形態をさらに具体的に詳しく説明する。
【図１】ここに説明する実施形態が、不完全なビデオデータの復号も含めて、動作してもよいコンピュータアーキテクチャを示す図である。
【図２】不完全なビデオデータを復号する方法の一例を示すフローチャートである。
【図３】不完全なビデオデータを復号する方法の別の一例を示すフローチャートである。
【図４】不完全なビデオデータを復号する方法のもう一つ別の一例を示すフローチャートである。
【図５】フレームピースが順次的に復号される一実施形態を示す図である。
【図６】フレームピースが復号され合成される一実施形態を示す図である。
【図７】フレームピースがＨ．２６４チャネルで復号される一実施形態を示す図である。
【発明を実施するための形態】
【０００８】
ここに説明する実施形態は、不完全なビデオデータの復号に関する。一実施形態では、コンピュータシステムはフレームのピース（ａ  ｐｉｅｃｅ  ｏｆ  ａ  ｆｒａｍｅ）（例えば、ビデオフレーム）を受信する。フレームは、複数のフレームピースを含み、各フレームピースは個別に復号可能であるように符号化される。コンピュータシステムは、少なくとも１つの追加フレームピースを受信するのを待ちつつ、受信したフレームピースを復号する。次いで、フレームが不完全であることを示す状態が発生すると、コンピュータシステムは、まだ受信されていない追加フレームピースを置き換えるフレームピースを合成する。
【０００９】
他の一実施形態では、フレームのピースの受信に応じて、コンピュータシステムは、他のフレームピースが受信されるのを待ちつつ、受信したフレームピースを復号する。コンピュータシステムは、フレームが不完全であり、そのフレームには少なくとも１つのまだ受信される予定の追加フレームピースがあることを示す状態の発生を検出する。次いで、その発生の検出に応じて、コンピュータシステムは、まだ受信される予定の追加フレームを置き換えるフレームピースを合成する。
【００１０】
他の一実施形態では、コンピュータシステムは、複数のフレームピースを含むフレームの１つのフレームピースにアクセスする。各フレームピースは個別に復号可能である。コンピュータシステムは、追加フレームピースが受信されるのを待ちつつ、アクセスしたフレームピースを復号する。コンピュータシステムは、少なくとも１つの追加フレームピースがまだ受信される予定であると判断し、その判断に応じて、前のフレームに関連するフレームデータを用いてフレームピースを合成する。
【００１１】
以下の説明では、実行してもよい複数の方法及び方法動作に言及する。留意点として、方法動作はある順序で説明され、又はある順序で行うとフローチャートで例示するが、特に断らなければ、特定の順序は必ずしも必要ない。または、ある動作は、それが実行される前に他の動作が完了していることに依存するため、特定の順序が必要となる。
【００１２】
ここに説明する実施形態は、様々なタイプの計算システムを実施してもよい。これらの計算システムは、ますますバラエティに富んだ形式を取っている。計算システムは、例えば、ハンドヘルドデバイス、電化製品、ラップトップコンピュータ、デスクトップコンピュータ、メインフレーム、分散コンピューティングシステム、又は従来は計算システムと考えられていなかったデバイスであってもよい。この説明及びクレームにおいて、「計算システム」との用語は、少なくとも１つの物理的かつ有体のプロセッサと、プロセッサにより実行されてもよいコンピュータ実行可能命令を格納することができる物理的かつ有体のメモリとを含む任意のデバイス又はシステム（又はこれらの組み合わせ）を含むものと広く定義される。計算システムは、ネットワーク環境にわたり分散していてもよく、構成要素である複数の計算システムを含んでいてもよい。
【００１３】
図１に示したように、計算システム１０１は、一般的に、少なくとも１つの処理部１０２Ａとメモリ１０３Ａとを含む。メモリ１０３Ａは物理的システムメモリであってもよく、これは揮発性、不揮発性、又は両者の組み合わせであってもよい。「メモリ」との用語は、ここでは、物理的記憶媒体などの不揮発性マスストレージを指して使われても良い。計算システムが分散している場合、処理、メモリ、及び／又は記憶機能も分散していてもよい。
【００１４】
ここで、「実行可能モジュール」又は「実行可能コンポーネント」との用語は、ソフトウェアオブジェクト、ルーチン、又は方法であって計算システム上で実行してもよいものを指し得る。ここに説明する異なるコンポーネント、モジュール、エンジン、及びサービスは、（例えば、別のスレッドとして）計算システム上で実行されるオブジェクト又はプロセスとして実施してもよい。
【００１５】
以下の説明では、実施形態を、一以上の計算システムにより実行される動作を参照して説明する。かかる動作がソフトウェアで実装されている場合、その動作を実行する計算システムの一以上のプロセッサは、コンピュータ実行可能命令の実行に応じて、計算システムの動作を命じる。例えば、かかるコンピュータ実行可能命令は、コンピュータプログラム製品を構成する一以上のコンピュータ読み取り可能媒体に実施してもよい。かかる動作の一例はデータの操作を含む。コンピュータ実行可能命令（及び操作されたデータ）は、計算システム１０１のメモリ１０３Ａに格納されてもよい。計算システム１０１は、それが有線又は無線ネットワークにより他のメッセージプロセッサと通信できるようにする通信チャンネルを有していてもよい。
【００１６】
ここに説明する実施形態は、以下により詳しく説明するように、例えば一以上のプロセッサとシステムメモリなどのコンピュータハードウェアを含む特定目的又は汎用コンピュータシステムを含み、又は利用してもよい。システムメモリは全体メモリ１０３Ａ内に含まれていてもよい。システムメモリは、「メインメモリ」とも呼ばれ、メモリバスにより少なくとも１つの処理部１０２Ａによりアドレッシング可能なメモリロケーションを含む。この場合、アドレスロケーションはメモリバス自体によってアサートされる。システムメモリは、従来は揮発性であったが、ここに説明する原理は、システムメモリが部分的に又は完全に不揮発性である場合にも当てはまる。
【００１７】
また、本発明の範囲内の実施形態は、コンピュータ実行可能命令及び／又はデータ構造を担う又は格納する物理的その他のコンピュータ読み取り可能媒体を含む。かかるコンピュータ読み取り可能媒体は、汎用又は特殊目的コンピュータシステムによりアクセスできる、利用できるどんな媒体であってもよい。コンピュータ実行可能命令及び／又はデータ構造を格納するコンピュータ読み取り可能媒体は、コンピュータ記憶媒体である。コンピュータ実行可能命令及び／又はデータ構造を担うコンピュータ読み取り可能媒体は、伝送媒体である。このように、限定ではなく例として、本発明の実施形態は、区別でき異なる少なくとも２種類のコンピュータ読み取り可能媒体、すなわち、コンピュータ記憶媒体と伝送媒体とを含み得る。
【００１８】
コンピュータ記憶媒体は、コンピュータ実行可能命令及び／又はデータ構造を記憶する物理的ハードウェア記憶媒体である。物理的ハードウェア記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、半導体ドライブ（ＳＳＤ）、フラッシュメモリ、相変化メモリ（ＰＣＭ）、光ディスクストレージ、磁気ディスクストレージその他の磁気ストレージデバイス、又はその他の任意のハードウェアストレージデバイスであってコンピュータ実行可能命令又はデータ構造の形式のプログラムデータを記憶するのに使え、汎用又は特殊用途コンピュータシステムによりアクセス及び実行でき、本発明の開示の機能を実施できるものなどのコンピュータハードウェアを含む。
【００１９】
送信媒体は、コンピュータ実行可能命令又はデータ構造の形式のプログラムコードを担うのに用いることができ、汎用又は特殊用途コンピュータシステムによりアクセスできるネットワーク及び／又はデータリンクを含み得る。「ネットワーク」はコンピュータシステム及び／又はモジュール及び／又はその他の電子デバイス間での電子データの送信を可能にする一以上のデータリンクとして定義される。ネットワークその他の通信接続（有線、無線、又は有線と無線の組み合わせを問わない）によりコンピュータシステムに情報が転送又は供給されるとき、コンピュータシステムは、その接続を伝送媒体として見ることがある。上記のものの任意の組合せも、コンピュータ読み取り可能媒体の範囲内に含まれる。
【００２０】
さらに、様々なコンピュータシステムコンポーネントに到達するとき、コンピュータ実行可能命令又はデータ構造の形式のプログラムコードは、伝送媒体からコンピュータストレージ媒体に（又はその逆に）自動的に転送され得る。例えば、ネットワーク又はデータリンクにより受信したコンピュータ実行可能命令又はデータ構造は、ネットワークインターフェースモジュール（例えば、ＮＩＣ）中のＲＡＭにバッファでき、その後最終的にコンピュータシステムのコンピュータシステムＲＡＭ及び／又は揮発性の低いコンピュータストレージ媒体に転送される。このように、言うまでもなく、コンピュータストレージ媒体は、伝送媒体も（又は伝送媒体を主に）利用するコンピュータシステムコンポーネントに含まれ得る。
【００２１】
コンピュータ実行可能命令は、例えば、命令とデータであって、一以上のプロセッサで実行されると、汎用コンピュータシステム、特殊用途コンピュータシステム、又は特殊用途処理デバイスに、ある機能又は一群の機能を実行させるものを含む。コンピュータ実行可能命令は、例えば、バイナリ、アセンブリ言語などの中間フォーマット命令、又はソースコードなどであってもよい。
【００２２】
本技術分野の当業者には言うまでもなく、ここに説明の原理は、多くのタイプのコンピュータシステム構成を有するネットワークコンピューティング環境で実施してもよい。コンピュータシステム構成には、パーソナルコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、メッセージプロセッサ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベース又はプログラマブルコンシューマエレクトロニクス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、携帯電話、ＰＤＡ、タブレット、ページャ、ルータ、スイッチなどを含む。本発明は、ローカル及びリモートコンピュータシステムがネットワークを通してリンク（有線データリンク、無線データリンク、又は有線データリンクと無線データリンクの組み合わせ）されていて、それらが両方ともタスクを実行する分散システム環境で実施してもよい。そのため、分散システム環境では、コンピュータシステムは構成要素の複数のコンピュータシステムを含んでいてもよい。分散システム環境では、プログラムモジュールは、ローカル及びリモートのメモリ記憶デバイスの両方に配置できる。
【００２３】
本技術分野の当業者には言うまでもなく、本発明はクラウドコンピューティング環境で実施してもよい。クラウドコンピューティング環境は分散していてもよいが、これは必ずしも必要ない。分散している場合、クラウドコンピューティング環境は、ある組織内で国際的に分散していてもよく、複数の組織にまたがって所有されるコンポーネントを有していても良い。この説明及び以下の請求項において、「クラウドコンピューティング」は、構成可能な計算リソース（例えば、ネットワーク、サーバ、ストレージ、アプリケーション、及びサービス）の共有プールへのオンデマンドネットワークアクセスを可能にするモデルとして定義される。「クラウドコンピューティング」の定義は、適切に展開されたとき、かかるモデルから得られる他の多くの利点のどれにも限定されない。
【００２４】
さらにまた、ここに説明のシステムアーキテクチャは、それぞれがシステムの全体としての機能に貢献する、独立した複数のコンポーネントを含み得る。このモジュール性により、プラットフォームスケーラビリティの問題にアプローチするときの柔軟性が改善し、この目的を達成するため、様々な利点を提供する。機能範囲が限定されたより小さいスケールのパーツを用いることにより、システムの複雑性及び成長をより容易に管理することができる。これらの弱く結合したモジュールの使用により、プラットフォームの耐故障性が向上する。個々のコンポーネントは、ビジネスニーズに応じて、徐々に成長できる。モジュール開発は、新しい機能のタイムツーマーケットの短縮にもつながる。コアシステムに影響を与えずに、新しい機能を追加又は削除できる。
【００２５】
図１は、少なくとも１つの実施形態が利用され得るコンピュータアーキテクチャ１００を示す。コンピュータアーキテクチャ１００は、コンピュータシステム１０１を含む。コンピュータシステム１０１と１１３は、任意のタイプのローカル又は分散コンピュータシステムであってもよく、クラウドコンピューティングシステムを含んでいてもよい。それぞれ少なくとも１つのプロセッサ１０２Ａ／１０２Ｂ、メモリ１０３Ａ／１０３Ｂ及び通信モジュール１０４Ａ／１０４Ｂを含む。通信モジュールは、有線又は無線ネットワークカード、ブルートゥース(登録商標)無線通信部、Ｗｉｆｉ無線通信部、又はその他のデジタルデータを送受信するように構成されたハードウェアを含む有線又は無線通信手段を含んでいてもよい。通信モジュール１０４Ａは、例えば、コンピュータシステム１１３の通信モジュール１０４Ｂから、フレーム１１１又はフレームピース１１０を受信してもよい。
【００２６】
幾つかの実施形態では、コンピュータシステム１１３はサーバであってもよい。サーバは、単一のコンピュータシステムであってもよく、分散していてもよい。サーバは、データを、コンピュータシステム１０１などのクライアントに提供するように構成されていてもよい。サーバは、データの入力又はその他の要求に応じて、クライアントにアプリケーションデータを提供してもよい。幾つかの実施形態では、コンピュータシステム１１３はビデオゲームサーバであってもよい。かかる場合、ビデオゲームサーバは、ビデオゲームコンテンツを有するフレームを提供するように構成されていてもよい。これらのフレームは、符号化されていてもよく、少なくとも幾つかの場合には、原データ（ｒａｗ  ｆｏｒｍ）であってもよい。フレームは、フルフレーム形式１１１又はピース１１０で送信されてもよい。ピース（ｐｉｅｃｅｓ）はデータパケットを介して送信されてもよく、各ピースは一以上のデータパケットを含んでいてもよい。そのため、フレームピースはコンピュータシステム１０１に転送され、次いで結合されてフルフレームを形成する。これらのフレームピースは、動画を構成する連続した一連のフレームを構成するため、連続したストリーミング方式で送信されてもよい。ゲームシナリオでは、このフレームストリームはビデオゲーム出力を構成するだろう。言うまでもなく、ビデオゲームの実施形態は、ここでは頻繁に言及するが、ビデオコンテンツが１つのコンピュータシステムから他のコンピュータシステムに転送される（すなわち、ストリーミングされる）単なる一実施形態の一例である。実際、不完全なデータの復号は、以下に説明するように、ビデオデータがロッシー（ｌｏｓｓｙ）なネットワークにより送信される異なる様々なシナリオで実装してもよい。
【００２７】
フレーム１１１とフレームピース１１０を転送しやすくするために、これらは転送前に何らかの方法で符号化されることが多い。幾つかの実施形態では、フレームはＨ．２６４フォーマットにより符号化されてもよい。他の実施形態では、他のフォーマットを用いても良い。コンピュータシステム１１３の符号化モジュール１１４は、選択された符号化もーマットにより、フルフレーム及び／又はフレームピース１１０を符号化してもよい。これらの符号化されたフレーム又はフレームピースは、コンピュータシステム１０１に転送され、そこで復号され、ディスプレイ１０８に表示される。復号モジュール１０５は、受信したフレーム１１１及びフレームピース１１０を復号し、ユーザに表示するためディスプレイ１０８に送る。幾つかの実施形態では、復号モジュール１０５は、幾つかのフレームピースが失われても、フレームピース１１０を表示するように構成されていてもよい。実際、データパケットが失われるネットワークトランザクションでは、幾つかのフレームピース又はその一部が失われ、又は転送中に遅延することがある。かかる場合に、復号モジュールは、失われた又は遅延したピースが現れるのを待ちつつ、受信したフレームピース１１０を復号し続ける。失われた又は遅延したピースが現れるのが間に合わないとき、フレーム合成モジュール１０７は、様々なフレーム合成手法を用いてフレームを合成してもよい。
【００２８】
例えば、フレーム合成モジュール１０７は、その前の一以上のフレームのフレームデータを見て、失われた又は遅延したフレームピースを合成してもよい。フレーム合成モジュール１０７は、失われたフレームピースが、現在復号されており、表示する準備がされているフレームの左上角にあると判断してもよい。フレーム合成モジュール１０７は、前の一以上のフレームの左上角のフレームデータを見て、そのフレームのその部分がどう見えるか（例えば、青空か、都市背景かなど）確認する。次いで、このデータに基づいて、フレーム合成モジュール１０７は、失われたフレームピースを合成して、フレームがほぼ正しく見えるようにしてもよい。しかし、忠実性は幾分失われる可能性がある。この点において、コンピュータシステム１０１は、コンピュータシステム１１３に、少なくとも１つのフレームピースが失われた又は大幅に遅延したこと、及びフルフレーム１１１が送信されることを示す表示（ｉｎｄｉｃａｔｉｏｎ）１１２を送信してもよい。次いで、フレーム差分を送信（すなわち、変化したフレームの部分のみを送信）する替わりに、フルフレーム１１１が送信され、又は正しくないピクセルを修正する他の何らかのリフレッシュ（ｒｅｆｒｅｓｈ）が行われる。留意点として、他の多くの方法や手法を用いて失われたフレームピースを合成してもよい。これらのフレーム合成方法その他のコンセプトは、図２、３及び４のそれぞれ方法２００、３００及び４００を参照して、以下により詳しく説明する。
【００２９】
以下に説明するシステム及びアーキテクチャを考慮して、開示の手段により実施されてもよい方法は、図２、３及び４のフローチャートを参照してより良く理解されるだろう。説明を単純にするために、方法を一連のブロックとして図示して説明する。しかし、言うまでもなく、請求項に係る主題は、ブロックの順序には限定されない。幾つかのブロックは、ここに図示して説明するものとは異なる順序で、及び／又は他のブロックと同時に行われてもよいからである。さらに、以下に説明する方法を実装するのに、例示されるブロックのすべてが必要ではないかも知れない。
【００３０】
図２は、不完全なビデオデータを復号する方法２００を示すフローチャートである。環境１００のコンポーネント及びデータを頻繁に参照して、方法２００をここで説明する。
【００３１】
方法２００は、少なくとも１ピースのフレームを受信する動作を含む。フレームは複数のフレームピースを含み、各フレームピース自体は、個別の復号可能なように、符号化される（動作２１０）。例えば、コンピュータシステム１０１の通信モジュール１０４Ａは、コンピュータシステム１１３の通信モジュール１０４Ｂからフレームピース１１０を受信してもよい。フレームピース１１０はそれだけで送信されても、他のピースと組み合わせて送信されてもよい。さらに、フレームピース自体は単一のデータパケットで送信されてもよく、複数のデータパケットに分割されてもよい。フレームピース１１０は、フルフレーム（例えば、１１１）の１ピースであり、そのため、対応する他のフレームピースと組み合わせられると、フルフレームとなる。フレームは実質的に幾つのフレームピースに分割されてもよい。これらのピースは、転送され、再アセンブルされてフルフレームを形成する。幾つかの実施形態では、フレームピースは、コンピュータシステム１０１に転送される前に、符号化モジュール１１４により符号化されてもよい。フレームは異なるさまざまな符号化フォーマットのどれで符号化されてもよい。これらの符号化フォーマットは、画質、転送効率（すなわち、帯域幅）、符号化の速さ、又はその他の点を考慮して最適化されてもよい。
【００３２】
各フレームピース１１０は、そのフレームピースが個別に復号できるように、個別に符号化されてもよい。このように、コンピュータシステム１０１の復号モジュールは、フレームピースを受け取り、それを他のフレームピースを受信せずに復号してもよい。次いで、他のフレームピースを受信後、他のフレームピースの受信を待ちつつ、復号モジュール１０５は、最も新しく受信したピースの復号を開始してもよい。実際、これは方法２００で説明した。方法２００は、少なくとも１つの追加のフレームピースが受信されるのを待ちつつ、受信したフレームピースの少なくとも１つを復号する動作を含む。このプロセスはさらに図５に示した。
【００３３】
図５は、図１の復号モジュール１０５と同じでもよく、異なってもよいデコーダ５０１を含む。デコーダ５０１は、フレームピース５０３Ａを前に受信し、その復号をすでに開始していてもよい。この復号されるフレームピース５０３Ａは、追加されてもよいし、フレーム５０５の構成を開始してもよい。フレーム５０５の下部の構成として示したが、言うまでもなく、復号されるフレームピース５０３は、フレームの実質的にどの部分のフレームデータを含んでもよく、フレーム中の１つのブロックのフレームデータを含んでもよく、フレームの異なる部分のフレームデータを含んでいてもよい。しかし、単純化のため、図５と図６に示したフレームピースは、互いに水平に重なっている。図５に示した、入来するフレームピース５０２Ｂ、５０２Ｃ及び５０２Ｄは、トランジットであり、デコーダ５０１によりまだ受信されていない。しかし、これらのフレームピースが受信されると、デコーダ５０１はそれらの復号を個別に開始できる。このように、受信されたフレームピース５０３Ａは、フレームピース５０２Ｂが受信されるのを待っている間に、復号され得る。同様に、フレームピース５０３Ｂは、フレームピース５０２Ｃが受信されるのを待っている間に、復号でき、フレームピース５０３Ｃは、フレームピース５０２Ｄが受信されるのを待っている間に復号でき、以下同様である。このように、デコーダ５０１は、現在有しているフレームデータを用いて復号プロセスを開始することができる。
【００３４】
フレームピースは順序通りでなく復号することもできる。フレームピースは、一般的にロッシー（ｌｏｓｓｙ）ネットワークにより転送され、各パケットの安全な伝送を補償しないプロトコル（例えば、ＵＤＰ）を用いて転送されてもよい。そのため、フレームピースは、様々な理由で失われたり、遅延したりすることがある。一例では、フレームピース５０２Ｃがフレームピース５０２Ｂより前に受信されるかも知れない。このような場合、デコーダ５０１は、フレームピース５０２Ｂを受信する前に、フレームピース５０２Ｃの復号を開始してもよい。次いで、フレームピース５０２Ｂが受信されると、復号され、フレーム５０５に追加される。最後に、フレーム５０５のすべてのコンポーネントピースが受信されると、フレームがディスプレイ５０４に表示される。ディスプレイは任意のタイプのモニタ、テレビジョン、タブレット、又は表示手段であってもよい。フレーム５０５は、一連のフレーム中の１つのフレームであってもよい。例えば、ストリーミングビデオ又はビデオゲームのシナリオでは、データストリーミングサーバが、かかるフレームを毎秒多数送信する。これらのフレームは、ディスプレイ５０４上に順次的に表示され、ユーザが見る動画を構成する。
【００３５】
図２に戻り、方法２００は、フレームが不完全であることを示す少なくとも１つの状態が成立した場合、一以上のフレームピースを合成して、まだ受信されていない少なくとも１つの追加フレームを置き換える動作（動作２３０）を含む。その状態は、例えば、一以上のフレームピースが失われ、又は遅延したとの判断を含んでいてもよい。状態モニタリングモジュール１０６は、入来するフレームピースをモニタするように構成され、フレームピースが失われたこと、又は大幅に遅延していることを判断してもよい。かかる判断がされると、フレーム合成モジュール１０７は、失われたフレームピースを合成して、合成したデータをフレームに挿入して、そのフレームを完成させてもよい。
【００３６】
図６に示すように、復号されたフレームピースは、合成されたフレームピースと結合され、フレームを形成してもよい。デコーダ６０１は、図５を参照して上で説明したように、フレームピースを受信する。図示したように、フレーム６０７はすでに復号されたフレームピース６０５Ａを含む。フレームピース６０５Ａは、フレームピース６０２Ｂ、６０２Ｃ、６０２Ｄ、６０２Ｅ以下同様を待っている間に、復号されてもよい。図１の状態モニタリングモジュール１０６は、フレームピース６０４Ｂが失われ又は遅延したと判断し、フレーム合成モジュール１０７にフレームピース６０４Ｂの合成を開始させていてもよい。合成されるデータは、図３を参照して下で説明するように、様々な方法で取得されてもよい。合成されたフレームピース６０４Ｂは、実際のフレームピースが挿入されるはずだったフレーム６０７の部分に、挿入されてもよい。デコーダ６０１は、合成器が他のフレームピースを合成している間に、フレームピースの復号を続けても良い。このように、フレームピース６０２Ｃは、受信され、復号され、復号フレームピース６０５Ｃとなる。６０２Ｄや６０２Ｅなどの他のフレームピースも、合成器が失われた又は遅延したフレームピースのデータを合成している間に、受信され、復号される。
【００３７】
図１に戻って、状態モニタリングモジュール１０６は、フレーム１１１が不完全であることを示す状態が発生したことを判断してもよい。この状態は、指定された最小閾値数のフレームピースが受信され、フレームピース合成が行われることの表示を含んでもよい。このように、例えば、フレーム毎又は一連のフレーム毎に、フレームピースの最小数を決めてもよい。フレームピースの最小数に達したら、そのフレームは合成により補正できると見なされても良い。そのため、フレームは、残りのフレームピースの再生成（すなわち、合成）が許される十分な受信データを含む。このフレームピースの最小数は、アドミニストレータ、プログラマ、又はその他のユーザにより設定されてもよい。
【００３８】
最小数のフレームピースが受信されていない場合、又は合成が可能ではない又は（例えば、多くのアーティファクトが発生してしまい）望ましくない場合、コンピュータシステム１０１は、フレーム置換データを送信するべきことを示す表示１１２を生成してもよい。少なくとも幾つかの実施形態では、フレーム置換データはフルフレーム（例えば、１１１）である。表示１１２が計算システム１１３に送信され、計算システム１１３はフルフレーム１１１を送信して応答する。この受信されたフレームデータは、（フレームピースが送信されたとき）既存のフレームに組み込まれても良く、フルフレームとして組み込まれてもよい。
【００３９】
このように、図２の方法２００で説明したように、ビデオフレーム情報を用いて、低レベルのパケットロスを検出した時にどうするか判断し、かかる倍には、データが失われた時には、復号レイテンシ及び視覚的破損を最小化する。実施形態は、ネットワークにより入来する低レベルデータパケットを処理し、そのデータパケットをフレーム及びフレームピースによりトラッキング及びグループ分けし、他のフレームデータパケットが到着するのを待っている間に、グループ分けしたフレームピースを復号モジュール１０５に供給する。フレームピースのデータパケットがエラー訂正により回復できないとき、部分的フレームピースは、リフレッシュが行える（すなわち、フルフレーム１１１が送信される）まで、視覚的破損（ｖｉｓｕａｌ  ｃｏｒｒｕｐｔｉｏｎ）を最小化する合成データにより、完成又は置換される。これによりさらに、有効データを供給することによりロバストなエラー隠蔽機能を有しないビデオデコーダの使用が可能となる。
【００４０】
実際、幾つかの実施形態では、コンピュータシステム１０１は、受信したフレームピース１１０の少なくとも１つが、フォワードエラーコレクションデータ（ｆｏｒｗａｒｄ  ｅｒｒｏｒ  ｃｏｒｒｅｃｔｉｏｎ  ｄａｔａ）を含むと判断してもよい。この前方エラー訂正（ＦＥＣ）データを実施して、フレームピース中のエラーを修正し、最終的にそのフレームピースを用いてフレームを構成してもよい。かかる場合、フレームピースは、前方エラー訂正が開始される前に復号されてもよい。他の実施形態では、コンピュータシステム１０１は、完全なフレームピースの復号を続ける間に、受信されていないフレームピースを有するフレームのＦＥＣ情報を待つように構成されていてもよい。このように、復号モジュール１０５は、（データパケットが失われ又は破損することにより）不完全な又は正しくないデータを有するフレームピースのＦＥＣデータを待つ間でも、フレームピースの復号を続けても良い。次いで、ＦＥＣ情報が対応するフレームピースのＦＥＣデータが受信されたとき、復号モジュール１０５は、ＦＥＣ補正フレームピースを復号して、そのフレームピースを他のフレームピースと組み合わせて、復号フレーム１０９を形成してもよい。このフレームはディスプレイ１０８に表示されてもよい。
【００４１】
図７は、Ｈ．２６４フォーマットを実装する一実施形態を示す。このフォーマットが使われるが、言うまでもなく、同様の手法で他のフォーマットを用いてもよい。フレームデータパケットは複数のフレームにわたりトラッキングされる。これにより、例えば、より前のフレームが完了されるべきであり、失われたパケットは到着せず、もう無いと考えるべきであることを、コンピュータシステムに表示するトラッキング情報が得られる。図７のＨ．２６４チャネル７０２はフレームトラッカーオブジェクト７０３Ａ、７０３Ｂ及び７０３Ｃを用い、フレームに関連するデータパケットと共に、現在進行中の既知のフレームをトラッキングする。これらのデータパケットは、ビデオ出力チャネル７０１又はその他のストリーミング源（例えば、リアルタイムトランスポートプロトコル（ＲＴＰ）ソース）から受信される。フレームピース（又は、ここでは「スライス」）は、各フレームの進行中のスライスの各々をトラッキングするスライストラッカーオブジェクト７０４Ａ、７０４Ｂ及び７０４Ｃによりトラッキングされる。これにより、コンピュータシステム１０１は、新しいフレームがいつ始まるか、前のフレームはどのくらい完全であったか、どのスライスが完全又は失われたが、フレームはいつ前方エラー訂正を必要とするかということなどを知ることができる。
【００４２】
Ｈ．２６４チャネル７０２は、前処理無しに、ビデオ出力チャネル７０１から原ＲＴＰデータパケット（又は他のプロトコルのデータパケット）を受信してもよい。タイムスタンプに基づき、フレームデータパケットは、すでにあるものが、又は新しく生成されたもの（例えば、７０３Ｃ）が、既存のフレームトラッカーオブジェクト（例えば、７０３Ａ）に送られる。フレームデータパケットペイロードは、フレームトラッカーにより受信された時に分析され、スライスネットワーク抽象レイヤユニット（ＮＡＬＵ）の開始を含む場合、新しいスライストラッカー（例えば、７０４Ｃ）が生成され、リストに追加される。フレームデータパケット（例えば、ＲＴＰパケット７０８）は、既存のスライスのシーケンス中の次の物であるとき、対応するスライストラッカーに送られる。そうでなければ、フレームデータパケットは、アウトオブオーダー（ＯＯＯ）パケットリスト（例えば、７０６）に保持されるか、もし複製であれば無視される。パケットは、前方エラー訂正（ＦＥＣ）データ（例えば、７０７）を含むとき、無くなったパケット（場合によっては、失われるパケットは１つだけである）の再生にすぐに使われるか、又はより多くのパケットが到着していれば、後で使う為、フレームトラッカーにより保持される。
【００４３】
少なくとも幾つかの実施形態では、フレームデータパケットは、スライストラッカー（例えば、７０４Ａ）に送られた場合、正しい順序であると仮定することができる。スライスの最後のフレームデータパケットが受信されると、スライスＮＡＬＵ（例えば、７０５）は、ビデオデコーダ（例えば、図１の１０５）に送られ得る。
【００４４】
あるフレーム１１１のスライス（例えば、フレームピース１１０）が完成され、デコーダ（例えば、１０５）に送信された場合、そのフレームは完成したものとみなされ（例えば、７０５）、チャネルがそのフレームをディスプレイ１０８に表示するため転送することができる。次のフレームのデータが到着し始めた時に、フレーム及びその一以上のスライスが完成していないとき、コンピュータシステム１０１は、エラー訂正により再生できないフレームデータは、無くなったと判断してもよい。かかる場合には、不完全なフレームデータにより生じるエラーを隠すために、フレームピース合成が行われる。失われたフレームピースは、フレーム合成モジュール１０７により合成され、復号モジュール１０５がフレームの処理を終了できるようにする。図７で説明したＨ．２６４実施形態では、失われた各スライスに対して、前の参照フレームのピクセルをコピーした合成スライスＮＡＬＵが構成される。合成スライスＮＡＬＵは復号のためデコーダ１０５に送られる。その後の完全なスライスも、フレームを形成するために送られる。これにより、フレームデータが不完全又は破損している場合に、完全な出力フレームを生じる。
【００４５】
破損したフレーム（すなわち、合成部分１０９を有する復号フレーム）は、その後のフレームからは参照されない場合、ディスプレイ１０８に表示でき、次のフレームは正常に処理される。フレームデータ破損は見えるが、１つのフレーム時間のみであり、後のフレームには伝搬しない。または、破損その他のデータ損失が十分大きければ、フレームは完全にドロップされ、まったく表示されないこともできる。破損フレームが参照フレーム（例えば、Ｈ．２６４フォーマットのＰフレーム）である場合、その破損はその後のフレームに伝搬する（実際、その後のフレームの基礎として用いられるフレームは、その破損は伝搬する）。かかる場合には、破損フレームは表示されるが、ビデオソースは、データロスが発生したことを、ビデオ出力チャネル７０１を介して通知される。これにより、ビデオプロバイダ（例えば、図１のコンピュータシステム１１３）は、（幾つかの場合には、次の又はその次で）破損のフレッシュかつ素早いクリーンアップをすぐにトリガーする。
【００４６】
ここで図３に戻り、フローチャートは、不完全なビデオデータを復号する方法３００を示す。環境１００のコンポーネント及びデータを頻繁に参照して、方法３００をここで説明する。
【００４７】
方法３００は、一以上のフレームピースの受信に応じて、少なくとも１つの追加フレームピースを受信するのを待っている間に、受信した一以上のピースを復号する動作（動作３１０）を含む。例えば、コンピュータシステム１０１の通信モジュール１０４Ａは、フレームピース１１０を受信してもよい。これは、結合されると、フルフレーム１１１を構成する。追加フレームピースが受信されるのを待っている間、復号モジュール１０５は、受信したフレームピースが順序通りでないとしても、受信したフレームピースの復号を開始してもよい。状態モニタリングモジュール１０６は、少なくとも１つの追加フレームがまだ受信されていないという点でフレームが不完全であることを示す状態の発生を検出してもよい（動作３２０）。この状態は、フレームピースのフレームデータがまだ受信されていない、又はフルフレームピースが受信されていないとの判断であり得る。追加的に又は代替的に、この状態は、後続の少なくとも１つのフレームピースを受信すること、又はあるピースのフレームデータが破損しているか、そうでなければ使えないと判断することであってもよい。
【００４８】
この検出動作に応じて、フレーム合成モジュール１０７は、まだ受信していない追加フレームピースを置き換えるフレームピースを合成してもよい（動作３３０）。合成は様々な異なる方法で行われても良いが、各方法は、失われた又は破損したデータの合成又は再生を行うことになる。幾つかの場合には、フレームピースを合成して受信されていないフレームピースを置き換えることは、前のフレームに関連するフレームデータを用いてフレームピースを合成することを含む。かかる場合には、フレーム合成モジュールは、以前の完全な一以上のフレームにアクセスし、分析して、現在のフレームが失われ又は破損しているフレームデータの部分のピクセルがどう見えるか判断してもよい。この情報を用いて、フレーム合成モジュール１０７は、前のフレームに現れたフレームデータと類似した、又は同一のフレームデータを生成してもよい。
【００４９】
さらに、フレーム合成モジュール１０７は、フレーム間の前の動きを決定する動作を含む様々なファクタを考慮してもよい。フレーム間の前の動きは、データが、合成されるフレームにおいてどのように変化し続けるかのインジケータであってもよい。さらに、フレーム合成モジュール１０７は、一以上の前のフレームに基づいて、カメラがどの方向にパンしているか判断してもよく、決定されたパン方向を用いてフレームピースを合成してもよい。よって、カメラが左から右にパンしていると判断されると、フレーム合成モジュール１０７は、フレームの右側にあったピクセルが、そのフレームの左側に徐々に近づく動きをすると判断する。動きベクトルを含む他のファクタを用いて、（除々に左から右へ又は上から下へのパンとは異なり）不規則な動きを決定し、現在のフレーム（すなわち、合成されるフレーム）がどう見えるべきかに関するその他のインジケータを提供してもよい。この情報を用いて、フレーム合成モジュール１０７は、フレームピースの失われたフレームデータを近似又は合成できる。これは前に復号したフレームピースと合成されて、完全なフレーム１１１を構成する。
【００５０】
図４は、不完全なビデオデータを復号する方法の別の一例（方法４００）を示すフローチャートである。環境１００のコンポーネント及びデータを頻繁に参照して、方法４００をここで説明する。
【００５１】
方法４００は少なくとも１つのフレームピースにアクセスする動作を含み、フレームは一以上のフレームピースを含み、各フレームピースは個別に復号可能である（動作４１０）。復号モジュール１０５は、少なくとも１つの追加フレームピースが受信されるのを待つ間に、一以上の受信フレームピース１１０にアクセスし、これらのフレームピースを復号する（動作４２０）。状態モニタリングモジュール１０６は、少なくとも１つの追加フレームピースがまだ受信されていないと判断し、フレームを不完全なままレンダリングする（動作４３０）。次いで、判断に応じて、フレーム合成モジュールは、少なくとも１つの前のフレームに関連するフレームデータを用いて、フレームピースを合成する。フレームとフレームピースは、図７に概略を示したように、別々にトラッキングされてもよい。複数のフレームにわたるフレームピースデータパケットをトラッキングすることにより、コンピュータシステム１０は、後続のフレームのデータパケットがいつ受信されるかを判断してもよい。後続フレームのデータパケットが受信されるとき、フレーム合成を開始させる表示又は状態であってもよい。
【００５２】
幾つかの実施形態では、フレームピーストラッキング及び／又はフレームトラッキングは、プロトコルベースシーケンス番号を用いて、インクリメント状に増加するタイムスタンプを用いて、又はその他のタイプの識別子を用いて、実装してもよい。プロトコルベースシーケンス番号又はインクリメント状に増加するタイムスタンプを、各フレーム及び／又は各フレームピースに割り当ててもよい。これにより、フレーム又はフレームピースを個別にトラッキングでき、その後、新しいフレームピース又はフレームのフレームデータを受信した時に、コンピュータシステム１０１にアラートを発することができる。例えば、フレーム及び／又はフレームピースは、ストリーミングされたビデオゲームの一部として受信されてもよい。ストリーミングされたビデオゲームは、一般的に、高いフレームレートで実行され、ユーザが遅れを感じないようにされる。かかるシナリオでは、コンピュータシステム１０１は、プロトコルベースシーケンス番号又はインクリメント状に増加するタイムスタンプを用いて、フレーム又はフレームピースが不完全であるか、及びそのフレームの部分を合成する必要があるか、素早く判断してもよい。不完全である（例えば、フレームピースデータパケットをフレームピース及び／又はフレームと関連付けるのに使われるタイムスタンプ情報が、新しいフレームが受信されることを示す）とき、フレーム合成モジュールは、失われた又は破損したフレームデータをすぐに合成できる。このように、フレームはすばやく完成でき、ゲームプレーヤに表示するため、ディスプレイ１０８に送信できる。
【００５３】
したがって、不完全なビデオデータを復号する方法、システム及びコンピュータプログラム製品を提供する。フレームピースは、フレームの他のピースを待っている間に、復号され得る。さらに、フレームデータのいずれかの部分が失われた又は破損したと判断されたとき、そのフレームのその部分を、その失われた又は破損したデータの見え方を近似するように、合成できる。
【００５４】
ここに説明のコンセプトとフィーチャ（ｆｅａｔｕｒｅｓ）は、その精神や説明した特徴から逸脱することなく、他の具体的な形式で実施してもよい。説明の実施形態は、すべての点で、例示であり限定ではないと考えなければならない。それゆえ、開示の範囲は、上記の説明ではなく、添付の特許請求の範囲により示される。請求項の意味又は均等の範囲内のすべての変更は、その範囲内に含まれる。
【図１】
0006637900.tif 000002
【図２】
0006637900.tif 000003
【図３】
0006637900.tif 000004
【図４】
0006637900.tif 000005
【図５】
0006637900.tif 000006
【図６】
0006637900.tif 000007
【図７】
0006637900.tif 000008