(57)【特許請求の範囲】
【請求項１】
前方誤り訂正（ＦＥＣ）によりフレームを符号化し送信する方法であって、
シーケンス内の現フレーム及び前記シーケンス内の１つ以上の前フレームを含む複数の未符号化フレームを受信または生成することと、
前記現フレームを第１のビットレートで符号化して、１つ以上の符号化ソースフレームを生成することと、
前記１つ以上の前フレームを、前記第１のビットレート以下の第２のビットレートで符号化して、１つ以上の符号化ＦＥＣフレームを生成することと、
前記１つ以上の符号化ソースフレームの内の一つの符号化ソースフレームに対する情報の一部を前記１つ以上の符号化ＦＥＣフレームとともに第１のパケットに入れ、前記一つの符号化ソースフレームに対する情報の残りを第２のパケットに入れることにより、前記１つ以上の符号化ソースフレーム及び前記１つ以上の符号化ＦＥＣフレームを、１つ以上のデータパケットにパケット化することと
を含み、
前記第２のパケットには前記符号化ＦＥＣフレームが全く含まれないが、前記第１のパケットに含まれる前記符号化ＦＥＣフレームにおける情報が、前記第１のパケットおよび前記第２のパケットにおける前記一つの符号化ソースフレームに対する情報を再構築するのに十分である、方法。
【請求項２】
前記第２のビットレートに対する前記第１のビットレートの比は、約１〜約１０の間である、請求項１に記載の方法。
【請求項３】
前記複数の未符号化フレームは、１つ以上の音声フレームを含む、請求項１に記載の方法。
【請求項４】
データネットワークを介して前記１つ以上のデータパケットを送信することは、無線リンクを介して前記１つ以上のデータパケットを送信することを含む、請求項１に記載の方法。
【請求項５】
前記１つ以上の符号化ソースフレーム及び前記１つ以上の符号化ＦＥＣフレームをパケット化することは、前記１つ以上のデータパケットの各データパケットにシーケンス情報を配置することを含み、
前記シーケンス情報は、前記１つ以上の符号化ソースフレーム及び前記１つ以上の符号化ＦＥＣフレームの前記シーケンス内の対応位置を特定する、請求項１に記載の方法。
【請求項６】
前記１つ以上の符号化ソースフレーム及び前記１つ以上の符号化ＦＥＣフレームをパケット化することは、前記１つ以上のデータパケットの各データパケットのヘッダにシーケンス情報を配置することを含み、
前記シーケンス情報は、前記１つ以上の符号化ソースフレーム及び前記１つ以上の符号化ＦＥＣフレームの前記シーケンス内の対応位置を特定する、請求項１に記載の方法。
【請求項７】
前記１つ以上の符号化ソースフレーム及び前記１つ以上の符号化ＦＥＣフレームをパケット化することは、前記１つ以上のデータパケットの各データパケットにシーケンス情報を配置することを含み、
前記シーケンス情報は、前記１つ以上の符号化ソースフレーム及び前記１つ以上の符号化ＦＥＣフレームの前記シーケンス内の対応位置を特定し、
前記シーケンス情報は、前記所与のデータパケットのペイロード内の符号化ＦＥＣフレームの番号、前記第１のビットレート、前記第２のビットレート、前記ペイロード内のどの符号化フレームが前記ソースフレームに対応し、前記ペイロード内のどの符号化フレームがＦＥＣフレームに対応するか、または前記ペイロード内の前記符号化ソースフレームもしくは前記符号化ＦＥＣフレームのシーケンス識別子、以上のうちのいずれか１つ以上を含む、請求項１に記載の方法。
【請求項８】
前記１つ以上のデータパケットは、１つ以上のユニフォームデータグラムプロトコル（ＵＤＰ）パケットを含む、請求項１に記載の方法。
【請求項９】
前記１つ以上のデータパケットをメモリに格納すること、またはデータネットワークを介して前記１つ以上のデータパケットを送信することは、前記１つ以上のデータパケットを前記メモリに格納して、前記データネットワークを介して前記１つ以上のデータパケットを送信することを含む、請求項１に記載の方法。
【請求項１０】
前記１つ以上のデータパケットをメモリに格納すること、またはデータネットワークを介して前記１つ以上のデータパケットを送信することは、前記データネットワークを介して前記１つ以上のデータパケットを送信することを含み、
前記方法はさらに、前記データネットワークを介した送信のバースト性損失の継続時間を特定することを含む、請求項１に記載の方法。
【請求項１１】
前記１つ以上のデータパケットをメモリに格納すること、またはデータネットワークを介して前記１つ以上のデータパケットを送信することは、前記データネットワークを介して前記１つ以上のデータパケットを送信することを含み、
前記方法はさらに、前記データネットワークを介した送信のバースト性損失の継続時間を特定することを含み、
前記１つ以上の前フレームを前記第１のビットレート以下の前記第２のビットレートで符号化して前記１つ以上の符号化ＦＥＣフレームを生成することは、前記データネットワークを介した送信のバースト性損失の前記特定した継続時間に対応する十分な数の前フレームを符号化することを含む、請求項１に記載の方法。
【請求項１２】
前記現フレームを第１のビットレートで符号化して、前記１つ以上の符号化ソースフレームを生成することは、前記現フレームをコーデックの第１のインスタンスにより符号化することを含み、
前記１つ以上の前フレームを、前記第１のビットレート以下の第２のビットレートで符号化して、１つ以上の符号化ＦＥＣフレームを生成することは、前記１つ以上の前フレームを前記コーデックの第２のインスタンスで符号化することを含む、
請求項１に記載の方法。
【請求項１３】
前記複数の未符号化フレームは、１つ以上の映像フレームを含む、請求項１に記載の方法。
【請求項１４】
前記複数の未符号化フレームは、ゲームインターフェースからの入力ストリームの１つ以上のフレームを含む、請求項１に記載の方法。
【請求項１５】
前記複数の未符号化フレームは、１つ以上の音声フレームを含み、
前記１つ以上の音声フレームのそれぞれは、２つ以上の音声チャネルに対応する情報を含む、請求項１に記載の方法。
【請求項１６】
前記複数の未符号化フレームは、１つ以上の音声フレームを含み、
前記１つ以上の音声フレームのそれぞれは、左チャネル及び右チャネルに対応する情報を含む、請求項１に記載の方法。
【請求項１７】
前記複数の未符号化フレームは、１つ以上の音声フレームを含み、
前記１つ以上の音声フレームのそれぞれは、左チャネル、右チャネル、及び１つ以上の追加チャネルに対応する情報を含む、請求項１に記載の方法。
【請求項１８】
前記複数の未符号化フレームは、１つ以上の音声フレームを含み、
前記１つ以上の音声フレームのそれぞれは、左チャネル、右チャネル、及び１つ以上の追加チャネルに対応する情報を含み、
前記現フレームを符号化することは、前記左及び右チャネル、並びに前記１つ以上の追加チャネルを前記第１のビットレートで符号化することを含み、
前記１つ以上の符号化ソースフレームをパケット化することは、前記符号化した左及び右チャネルを１つ以上の第１のデータパケットに配置することと、前記符号化した追加チャネルを１つ以上の第２のデータパケットに配置することを含む、請求項１に記載の方法。
【請求項１９】
前記複数の未符号化フレームは、１つ以上の音声フレームを含み、
前記１つ以上の音声フレームのそれぞれは、左チャネル、右チャネル、及び１つ以上の追加チャネルに対応する情報を含み、
前記現フレームを符号化することは、前記現フレームの前記左及び右チャネル、並びに前記１つ以上の追加チャネルに対応する情報を前記第１のビットレートで符号化することを含み、
前記１つ以上の前フレームをＦＥＣフレームとして符号化することは、前記１つ以上の前フレームの前記左チャネル、右チャネル、及び１つ以上の追加チャネルの組み合わせに対応する情報を前記第２のビットレートで符号化することを含み、
前記１つ以上の符号化ソースフレーム及び前記１つ以上の符号化ＦＥＣフレームをパケット化することは、前記現フレームの前記左及び右チャネルに対応する前記符号化した情報、並びに前記１つ以上の前フレームの前記左チャネル、右チャネル、及び１つ以上の追加チャネルの前記組み合わせに対応する前記符号化した情報を、１つ以上の第１のデータパケットに配置することと、前記現フレームの前記符号化した追加チャネルを、１つ以上の第２のデータパケットに配置することを含む、請求項１に記載の方法。
【請求項２０】
前記複数の未符号化フレームは、１つ以上の音声フレームを含み、
前記１つ以上の音声フレームのそれぞれは、第１の左チャネル、第１の右チャネル、第２の左チャネル、及び第２の右チャネルに対応する情報を含み、
前記現フレームを符号化することは、前記現フレームの前記第１及び第２の左チャネル並びに第１及び第２の右チャネルに対応する情報を前記第１のビットレートで符号化することを含み、
前記１つ以上の前フレームをＦＥＣフレームとして符号化することは、前記１つ以上の前フレームの前記第１及び第２の左チャネル並びに第１及び第２の右チャネルの組み合わせに対応する情報を前記第２のビットレートで符号化することを含み、
前記１つ以上の符号化ソースフレーム及び前記１つ以上の符号化ＦＥＣフレームをパケット化することは、前記現フレームの前記第１の左チャネル及び第１の右チャネルに対応する前記符号化した情報、並びに前記１つ以上の前フレームの前記第１及び第２の左チャネル並びに第１及び第２の右チャネルの前記組み合わせに対応する前記符号化した情報を、１つ以上の第１のデータパケットに配置することと、前記現フレームの前記第２の左チャネル及び第２の右チャネルに対応する前記符号化した情報を、１つ以上の第２のデータパケットに配置することを含む、請求項１に記載の方法。
【請求項２１】
前記複数の未符号化フレームは、１つ以上の音声フレームを含み、
前記１つ以上の音声フレームのそれぞれは、第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、及びセンターチャネルに対応する情報を含み、
前記現フレームを符号化することは、前記現フレームの前記第１及び第２の左チャネル、前記第１及び第２の右チャネル、及び前記センターチャネルに対応する情報を前記第１のビットレートで符号化することを含み、
前記１つ以上の前フレームをＦＥＣフレームとして符号化することは、前記１つ以上の前フレームの前記第１及び第２の左チャネル、前記第１及び第２の右チャネル、及び前記センターチャネルの組み合わせに対応する情報を前記第２のビットレートで符号化することを含み、
前記１つ以上の符号化ソースフレーム及び前記１つ以上の符号化ＦＥＣフレームをパケット化することは、前記現フレームの前記第１の左チャネル及び第１の右チャネルに対応する前記符号化した情報、並びに前記１つ以上の前フレームの前記第１及び第２の左チャネル、前記第１及び第２の右チャネル、及び前記センターチャネルの前記組み合わせに対応する前記符号化した情報を、１つ以上の第１のデータパケットに配置することと、前記現フレームの前記第２の左チャネル、前記第２の右チャネル、及び前記センターチャネルに対応する前記符号化した情報を、１つ以上の第２のデータパケットに配置することを含む、請求項１に記載の方法。
【請求項２２】
前記複数の未符号化フレームは、１つ以上の音声フレームを含み、
前記１つ以上の音声フレームのそれぞれは、第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、センターチャネル、及び重低音効果（ＬＦＥ）チャネルに対応する情報を含み、
前記現フレームを符号化することは、前記現フレームの前記第１及び第２の左チャネル、前記第１及び第２の右チャネル、及び前記センターチャネルに対応する情報を前記第１のビットレートで符号化することを含み、
前記１つ以上の前フレームをＦＥＣフレームとして符号化することは、前記１つ以上の前フレームの前記第１及び第２の左チャネル、前記第１及び第２の右チャネル、前記センターチャネル、及び前記ＬＦＥチャネルの組み合わせに対応する情報を前記第２のビットレートで符号化することを含み、
前記１つ以上の符号化ソースフレーム及び前記１つ以上の符号化ＦＥＣフレームをパケット化することは、前記現フレームの前記第１の左チャネル及び第１の右チャネルに対応する前記符号化した情報、並びに前記１つ以上の前フレームの前記第１及び第２の左チャネル、前記第１及び第２の右チャネル、前記センターチャネル、及び前記ＬＦＥチャネルの前記組み合わせに対応する前記符号化した情報を、１つ以上の第１のデータパケットに配置することと、前記現フレームの前記第２の左チャネル、前記第２の右チャネル、及び前記センターチャネルに対応する前記符号化した情報を、１つ以上の第２のデータパケットに配置することを含む、請求項１に記載の方法。
【請求項２３】
プロセッサモジュールと、
前記プロセッサに接続されたメモリであって、方法を実施するように構成された実行可能命令を含む前記メモリと、
を含むシステムであって、前記方法は、
現フレーム及び１つ以上の前フレームを含む複数の未符号化フレームを受信または生成することと、
前記現フレームを第１のビットレートで符号化して、１つ以上の符号化ソースフレームを生成することと、
前記１つ以上の前フレームを、前記第１のビットレート以下の第２のビットレートで符号化して、１つ以上の符号化ＦＥＣフレームを生成することと、
前記１つ以上の符号化ソースフレームの内の一つの符号化ソースフレームに対する情報の一部を前記１つ以上の符号化ＦＥＣフレームとともに第１のパケットに入れ、前記一つの符号化ソースフレームに対する情報の残りを第２のパケットに入れることにより、前記１つ以上の符号化ソースフレーム及び前記１つ以上の符号化ＦＥＣフレームを、１つ以上のデータパケットにパケット化することと
を含み、
前記第２のパケットには前記符号化ＦＥＣフレームが全く含まれないが、前記第１のパケットに含まれる前記符号化ＦＥＣフレームにおける情報が、前記第１のパケットおよび前記第２のパケットにおける前記一つの符号化ソースフレームに対する情報を再構築するのに十分である、システム。
【請求項２４】
コンピュータ可読命令を包含する非一時的コンピュータ可読記録媒体であって、前記命令は方法を実施するように構成され、前記方法は、
現フレーム及び１つ以上の前フレームを含む複数の未符号化フレームを受信または生成することと、
前記現フレームを第１のビットレートで符号化して、１つ以上の符号化ソースフレームを生成することと、
前記１つ以上の前フレームを、前記第１のビットレート以下の第２のビットレートで符号化して、１つ以上の符号化ＦＥＣフレームを生成することと、
前記１つ以上の符号化ソースフレームの内の一つの符号化ソースフレームに対する情報の一部を前記１つ以上の符号化ＦＥＣフレームとともに第１のパケットに入れ、前記一つの符号化ソースフレームに対する情報の残りを第２のパケットに入れることにより、前記１つ以上の符号化ソースフレーム及び前記１つ以上の符号化ＦＥＣフレームを、１つ以上のデータパケットにパケット化することと
を含み、
前記第２のパケットには前記符号化ＦＥＣフレームが全く含まれないが、前記第１のパケットに含まれる前記符号化ＦＥＣフレームにおける情報が、前記第１のパケットおよび前記第２のパケットにおける前記一つの符号化ソースフレームに対する情報を再構築するのに十分である、非一時的コンピュータ可読記録媒体。
【請求項２５】
１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームを含むデータパケットを復号化し再構築する方法であって、
複数のデータパケットを受信することであって、前記複数のデータパケットのいくつかのデータパケットは、第１のビットレートで符号化されたシーケンス内のソースフレームと、前記第１のビットレート以下の第２のビットレートでＦＥＣフレームとして符号化された前記シーケンス内の１つ以上の前フレームとに対応する符号化情報を含み、前記１つ以上の符号化ソースフレームの内の一つの符号化ソースフレームに対する情報の一部を前記１つ以上の符号化ＦＥＣフレームとともに第１のパケットに入れ、前記一つの符号化ソースフレームに対する情報の残りを第２のパケットに入れることにより、前記１つ以上の符号化ソースフレーム及び前記１つ以上の符号化ＦＥＣフレームは、１つ以上のデータパケットにパケット化され、前記第２のパケットには前記符号化ＦＥＣフレームが全く含まれないが、前記第１のパケットに含まれる前記符号化ＦＥＣフレームにおける情報が、前記第１のパケットおよび前記第２のパケットにおける前記一つの符号化ソースフレームに対する情報を再構築するのに十分である、前記複数のデータパケットを受信することと、
前記複数のデータパケットの前記データパケットから、前記１つ以上の符号化ソースフレーム及び前記１つ以上の前フレームに対応する前記符号化情報を、パッケージ解除することと、
前記１つ以上の符号化ソースフレームを復号化して、１つ以上の復号化ソースフレームを生成することと、
前記シーケンスの所定のソースフレームに対応する符号化情報が前記複数のデータパケットから欠けているか否かを判定することと、
前記所定のソースフレームに対応する、前記複数のデータパケット内の１つ以上の対応符号化ＦＥＣフレームを識別することと、
前記１つ以上の対応符号化ＦＥＣフレームを復号化して、１つ以上の復号化ＦＥＣフレームを生成することと、
前記１つ以上の復号化ＦＥＣフレームを使用して、前記所定のソースフレームに対応する再構築フレームを生成することと
を含む、方法。
【請求項２６】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、符号化音声フレームである、請求項２５に記載の方法。
【請求項２７】
前記複数のデータパケットを受信することは、ネットワークを介して前記複数のデータパケットを受信することを含む、請求項２５に記載の方法。
【請求項２８】
前記複数のデータパケットを受信することは、無線リンクを介して前記１つ以上のデータパケットを受信することを含む、請求項２５に記載の方法。
【請求項２９】
前記複数のデータパケット内の各データパケットは、前記ソースフレーム、及びＦＥＣフレームとして符号化された前記シーケンス内の前記１つ以上の前フレームに関する前記シーケンス内の対応位置を特定するシーケンス情報を含む、請求項２５に記載の方法。
【請求項３０】
前記複数のデータパケット内の各データパケットのヘッダは、前記ソースフレーム、及びＦＥＣフレームとして符号化された前記シーケンス内の前記１つ以上の前フレームに関する前記シーケンス内の対応位置を特定するシーケンス情報を含む、請求項２５に記載の方法。
【請求項３１】
前記複数のデータパケット内の各データパケットは、前記ソースフレーム、及びＦＥＣフレームとして符号化された前記シーケンス内の前記１つ以上の前フレームに関する前記シーケンス内の対応位置を特定するシーケンス情報を含み、
前記シーケンス情報は、前記所定のデータパケットのペイロード内の符号化ＦＥＣフレームの番号、前記第１のビットレート、前記第２のビットレート、前記ペイロード内のどの符号化フレームが前記ソースフレームに対応し、前記ペイロード内のどの符号化フレームがＦＥＣフレームに対応するか、または前記ペイロード内の前記符号化ソースフレームもしくは前記符号化ＦＥＣフレームのシーケンス識別子、以上のうちのいずれか１つ以上を含む、請求項２５に記載の方法。
【請求項３２】
前記１つ以上のデータパケットは、１つ以上のユニフォームデータグラムプロトコル（ＵＤＰ）パケットを含む、請求項２５に記載の方法。
【請求項３３】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の符号化映像フレームである、請求項２５に記載の方法。
【請求項３４】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、ゲームインターフェースからの入力ストリームの１つ以上の符号化フレームである、請求項２５に記載の方法。
【請求項３５】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の音声フレームに対応し、
前記１つ以上の音声フレームは、２つ以上の音声チャネルに対応する情報を含む、請求項２５に記載の方法。
【請求項３６】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の音声フレームに対応し、
前記１つ以上の音声フレームは、左チャネル及び右チャネルに対応する情報を含む、請求項２５に記載の方法。
【請求項３７】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の音声フレームに対応し、
前記１つ以上の音声フレームのそれぞれは、左チャネル、右チャネル、及び１つ以上の追加チャネルに対応する情報を含み、
前記ソースフレームに対応する前記符号化情報は、１つ以上の第１のデータパケット内に前記左及び右チャネルに対応する符号化情報、及び、１つ以上の第２のデータパケット内に前記１つ以上の追加チャネルに対応する符号化情報を含む、請求項２５に記載の方法。
【請求項３８】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の音声フレームに対応し、
前記１つ以上の音声フレームのそれぞれは、左チャネル、右チャネル、及び１つ以上の追加チャネルに対応する情報を含み、
前記ソースフレームに対応する前記符号化情報は、１つ以上の第１のデータパケット内に前記左及び右チャネルに対応する符号化情報を含み、
１つ以上の第２のデータパケット内に前記１つ以上の追加チャネルに対応する符号化情報を含み、
前記１つ以上の第１のデータパケットはさらに、前記１つ以上の前フレームの前記左チャネル、右チャネル、及び１つ以上の追加チャネルの組み合わせに対応する前記第２のビットレートでの符号化情報を含む１つ以上の符号化ＦＥＣフレームを含む、請求項２５に記載の方法。
【請求項３９】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の音声フレームに対応し、
前記１つ以上の音声フレームのそれぞれは、左チャネル、右チャネル、及び１つ以上の追加チャネルに対応する情報を含み、
前記ソースフレームに対応する前記符号化情報は、１つ以上の第１のデータパケット内に前記左及び右チャネルに対応する符号化情報を含み、
１つ以上の第２のデータパケット内に前記１つ以上の追加チャネルに対応する符号化情報を含み、
前記１つ以上の第１のデータパケットはさらに、前記１つ以上の前フレームの前記左チャネル、右チャネル、及び１つ以上の追加チャネルの組み合わせに対応する前記第２のビットレートでの符号化情報を含む１つ以上の符号化ＦＥＣフレームを含み、
前記所定のソースフレームに対応する前記再構築フレームを生成することは、前記所定のソースフレームの前記１つ以上の追加チャネルに対応する欠落情報を、前記第１のデータパケットのうちの１つ以上のデータパケットにおける前記所定のソースフレームの前記左チャネル、右チャネル、及び１つ以上の追加チャネルの前記組み合わせに対応する前記情報から引き出すことと、前記欠落情報を、前記第１のデータパケットのうちの別の１つ以上のデータパケットから得た前記所定のソースフレームの前記左及び右チャネルに対応する復号化情報と組み合わせることを含む、請求項２５に記載の方法。
【請求項４０】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の音声フレームに対応し、
前記１つ以上の音声フレームのそれぞれは、左チャネル、右チャネル、及び１つ以上の追加チャネルに対応する情報を含み、
前記ソースフレームに対応する前記符号化情報は、１つ以上の第１のデータパケット内に前記左及び右チャネルに対応する符号化情報を含み、
１つ以上の第２のデータパケット内に前記１つ以上の追加チャネルに対応する符号化情報を含み、
前記１つ以上の第１のデータパケットはさらに、前記１つ以上の前フレームの前記左チャネル、右チャネル、及び１つ以上の追加チャネルの組み合わせに対応する前記第２のビットレートでの符号化情報を含む１つ以上の符号化ＦＥＣフレームを含み、
前記所定のソースフレームに対応する前記再構築フレームを生成することは、前記所定のソースフレームの前記左及び右チャネルに対応する欠落情報を、前記第１のデータパケットのうちの１つ以上のデータパケットにおける前記所定のソースフレームの前記左チャネル、右チャネル、及び１つ以上の追加チャネルの前記組み合わせに対応する前記情報から引き出すことと、前記欠落情報を、前記第２のデータパケットのうちの１つのデータパケットから得た前記所定のソースフレームの前記１つ以上の追加チャネルに対応する復号化情報と組み合わせることを含む、請求項２５に記載の方法。
【請求項４１】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の音声フレームに対応し、
前記１つ以上の音声フレームのそれぞれは、左チャネル、右チャネル、及び１つ以上の追加チャネルに対応する情報を含み、
前記ソースフレームに対応する前記符号化情報は、１つ以上の第１のデータパケット内に前記左及び右チャネルに対応する符号化情報を含み、
１つ以上の第２のデータパケット内に前記１つ以上の追加チャネルに対応する符号化情報を含み、
前記１つ以上の第１のデータパケットはさらに、前記１つ以上の前フレームの前記左チャネル、右チャネル、及び１つ以上の追加チャネルの組み合わせに対応する前記第２のビットレートでの符号化情報を含む１つ以上の符号化ＦＥＣフレームを含み、
前記所定のソースフレームに対応する前記再構築フレームを生成することは、前記所定のソースフレームの前記左及び右チャネル並びに前記１つ以上の追加チャネルに対応する欠落情報を、前記第１のデータパケットのうちの１つ以上のデータパケットにおける前記所定のソースフレームの前記左チャネル、右チャネル、及び１つ以上の追加チャネルの前記組み合わせに対応する前記情報から引き出すことを含む、請求項２５に記載の方法。
【請求項４２】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の音声フレームに対応し、
前記１つ以上の音声フレームのそれぞれは、第１の左チャネル、第１の右チャネル、第２の左チャネル、及び第２の右チャネルに対応する情報を含み、
前記ソースフレームに対応する前記符号化情報は、１つ以上の第１のデータパケット内に前記第１の左チャネル及び第１の右チャネルに対応する符号化情報、及び、１つ以上の第２のデータパケット内に前記第２の左チャネル及び第２の右チャネルに対応する符号化情報を含み、
前記１つ以上の第１のデータパケットはさらに、前記１つ以上の前フレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、及び第２の右チャネルの組み合わせに対応する前記第２のビットレートでの符号化情報を含む１つ以上の符号化ＦＥＣフレームを含み、
前記所定のソースフレームに対応する前記再構築フレームを生成することは、前記所定のソースフレームの前記第２の左チャネル及び第２の右チャネルに対応する欠落情報を、前記第１のデータパケットのうちの１つ以上のデータパケットにおける前記所定のソースフレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、及び第２の右チャネルの前記組み合わせに対応する前記情報から引き出すこと、及び、前記欠落情報を、前記第１のデータパケットのうちの別の１つ以上のデータパケットから得た前記所定のソースフレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、及び第２の右チャネルに対応する復号化情報と組み合わせることを含む、請求項２５に記載の方法。
【請求項４３】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の音声フレームに対応し、
前記１つ以上の音声フレームのそれぞれは、第１の左チャネル、第１の右チャネル、第２の左チャネル、及び第２の右チャネルに対応する情報を含み、
前記ソースフレームに対応する前記符号化情報は、１つ以上の第１のデータパケット内に前記第１の左チャネル及び第１の右チャネルに対応する符号化情報、及び、１つ以上の第２のデータパケット内に前記第２の左チャネル及び第２の右チャネルに対応する符号化情報を含み、
前記１つ以上の第１のデータパケットはさらに、前記第２のビットレートで前記１つ以上の前フレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、及び第２の右チャネルの組み合わせに対応する符号化情報を含む１つ以上の符号化ＦＥＣフレームを含み、
前記所定のソースフレームに対応する前記再構築フレームを生成することは、前記所定のソースフレームの前記第１の左チャネル及び第１の右チャネルに対応する欠落情報を、前記第１のデータパケットのうちの１つ以上のデータパケットにおける前記所定のソースフレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、及び第２の右チャネルの前記組み合わせに対応する前記情報から引き出すこと、及び、前記欠落情報を、前記第２のデータパケットのうちの１つのデータパケットから得た前記所定のソースフレームの前記第２の左チャネル及び第２の右チャネルに対応する復号化情報と組み合わせることを含む、請求項２５に記載の方法。
【請求項４４】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の音声フレームに対応し、
前記１つ以上の音声フレームのそれぞれは、第１の左チャネル、第１の右チャネル、第２の左チャネル、及び第２の右チャネルに対応する情報を含み、
前記ソースフレームに対応する前記符号化情報は、１つ以上の第１のデータパケット内に前記第１の左チャネル及び第１の右チャネルに対応する符号化情報、及び、１つ以上の第２のデータパケット内に前記第２の左チャネル及び第２の右チャネルに対応する符号化情報を含み、
前記１つ以上の第１のデータパケットはさらに、前記第２のビットレートで前記１つ以上の前フレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、及び第２の右チャネルの組み合わせに対応する符号化情報を含む１つ以上の符号化ＦＥＣフレームを含み、
前記所定のソースフレームに対応する前記再構築フレームを生成することは、前記所定のソースフレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、及び第２の右チャネルに対応する欠落情報を、前記第１のデータパケットのうちの１つ以上のデータパケットにおける前記所定のソースフレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、及び第２の右チャネルの前記組み合わせに対応する前記情報から引き出すことを含む、請求項２５に記載の方法。
【請求項４５】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の音声フレームに対応し、
前記１つ以上の音声フレームのそれぞれは、第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、及びセンターチャネルに対応する情報を含み、
前記ソースフレームに対応する前記符号化情報は、１つ以上の第１のデータパケット内に前記第１の左チャネル及び第１の右チャネルに対応する符号化情報、及び、１つ以上の第２のデータパケット内に前記第２の左チャネル、第２の右チャネル、及びセンターチャネルに対応する符号化情報を含み、
前記１つ以上の第１のデータパケットはさらに、前記１つ以上の前フレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、及びセンターチャネルの組み合わせに対応する前記第２のビットレートでの符号化情報を含む１つ以上の符号化ＦＥＣフレームを含み、
前記所定のソースフレームに対応する前記再構築フレームを生成することは、前記所定のソースフレームの前記第２の左チャネル、第２の右チャネル、及びセンターチャネルに対応する欠落情報を、前記第１のデータパケットのうちの１つ以上のデータパケットにおける前記所定のソースフレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、及びセンターチャネルの前記組み合わせに対応する前記情報から引き出すことと、前記欠落情報を、前記第１のデータパケットのうちの別の１つ以上のデータパケットから得た前記所定のソースフレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、及び第２の右チャネルに対応する復号化情報と組み合わせることを含む、請求項２５に記載の方法。
【請求項４６】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の音声フレームに対応し、
前記１つ以上の音声フレームのそれぞれは、第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、及びセンターチャネルに対応する情報を含み、
前記ソースフレームに対応する前記符号化情報は、１つ以上の第１のデータパケット内に前記第１の左チャネル及び第１の右チャネルに対応する符号化情報、及び、１つ以上の第２のデータパケット内に前記第２の左チャネル、第２の右チャネル、及びセンターチャネルに対応する符号化情報を含み、
前記１つ以上の第１のデータパケットはさらに、前記１つ以上の前フレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、及びセンターチャネルの組み合わせに対応する前記第２のビットレートでの符号化情報を含む１つ以上の符号化ＦＥＣフレームを含み、
前記所定のソースフレームに対応する前記再構築フレームを生成することは、前記所定のソースフレームの前記第１の左チャネル及び第１の右チャネルに対応する欠落情報を、前記第１のデータパケットのうちの１つ以上のデータパケットにおける前記所定のソースフレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、及びセンターチャネルの前記組み合わせに対応する前記情報から引き出すことと、前記欠落情報を、前記第２のデータパケットのうちの１つのデータパケットから得た前記所定のソースフレームの前記第２の左チャネル、第２の右チャネル、及びセンターチャネルに対応する復号化情報と組み合わせることを含む、請求項２５に記載の方法。
【請求項４７】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の音声フレームに対応し、
前記１つ以上の音声フレームのそれぞれは、第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、及びセンターチャネルに対応する情報を含み、
前記ソースフレームに対応する前記符号化情報は、１つ以上の第１のデータパケット内に前記第１の左チャネル及び第１の右チャネルに対応する符号化情報、及び、１つ以上の第２のデータパケット内に前記第２の左チャネル、第２の右チャネル、及びセンターチャネルに対応する符号化情報を含み、
前記１つ以上の第１のデータパケットはさらに、前記第２のビットレートで前記１つ以上の前フレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、及びセンターチャネルの組み合わせに対応する符号化情報を含む１つ以上の符号化ＦＥＣフレームを含み、
前記所定のソースフレームに対応する前記再構築フレームを生成することは、前記所定のソースフレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、及びセンターチャネルに対応する欠落情報を、前記第１のデータパケットのうちの１つ以上のデータパケットにおける前記所定のソースフレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、及びセンターチャネルの前記組み合わせに対応する前記情報から引き出すことを含む、請求項２５に記載の方法。
【請求項４８】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の音声フレームに対応し、
前記１つ以上の音声フレームのそれぞれは、第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、センターチャネル、及び重低音効果チャネルに対応する情報を含み、
前記ソースフレームに対応する前記符号化情報は、１つ以上の第１のデータパケット内に前記第１の左チャネル及び第１の右チャネルに対応する符号化情報、及び、１つ以上の第２のデータパケット内に前記第２の左チャネル、第２の右チャネル、センターチャネル、及び重低音効果チャネルに対応する符号化情報を含み、
前記１つ以上の第１のデータパケットはさらに、前記１つ以上の前フレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、センターチャネル、及び重低音効果チャネルの組み合わせに対応する前記第２のビットレートでの符号化情報を含む１つ以上の符号化ＦＥＣフレームを含み、
前記所定のソースフレームに対応する前記再構築フレームを生成することは、前記所定のソースフレームの前記第２の左チャネル、第２の右チャネル、センターチャネル、及び重低音効果チャネルに対応する欠落情報を、前記第１のデータパケットのうちの１つ以上のデータパケットにおける前記所定のソースフレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、センターチャネル、及び重低音効果チャネルの前記組み合わせに対応する前記情報から引き出すことと、前記欠落情報を、前記第１のデータパケットのうちの別の１つ以上のデータパケットから得た前記所定のソースフレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、及び第２の右チャネルに対応する復号化情報と組み合わせることを含む、請求項２５に記載の方法。
【請求項４９】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の音声フレームに対応し、
前記１つ以上の音声フレームのそれぞれは、第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、センターチャネル、及び重低音効果チャネルに対応する情報を含み、
前記ソースフレームに対応する前記符号化情報は、１つ以上の第１のデータパケット内に前記第１の左チャネル及び第１の右チャネルに対応する符号化情報、及び、１つ以上の第２のデータパケット内に前記第２の左チャネル、第２の右チャネル、センターチャネル、及び重低音効果チャネルに対応する符号化情報を含み、
前記１つ以上の第１のデータパケットはさらに、前記１つ以上の前フレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、センターチャネル、及び重低音効果チャネルの組み合わせに対応する前記第２のビットレートでの符号化情報を含む１つ以上の符号化ＦＥＣフレームを含み、
前記所定のソースフレームに対応する前記再構築フレームを生成することは、前記所定のソースフレームの前記第１の左チャネル及び第１の右チャネルに対応する欠落情報を、前記第１のデータパケットのうちの１つ以上のデータパケットにおける前記所定のソースフレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、センターチャネル、及び重低音効果チャネルの前記組み合わせに対応する前記情報から引き出すことと、前記欠落情報を、前記第２のデータパケットのうちの１つのデータパケットから得た前記所定のソースフレームの前記第２の左チャネル、第２の右チャネル、センターチャネル、及び重低音効果チャネルに対応する復号化情報と組み合わせることを含む、請求項２５に記載の方法。
【請求項５０】
前記１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームは、１つ以上の音声フレームに対応し、
前記１つ以上の音声フレームのそれぞれは、第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、センターチャネル、及び重低音効果チャネルに対応する情報を含み、
前記ソースフレームに対応する前記符号化情報は、１つ以上の第１のデータパケット内に前記第１の左チャネル及び第１の右チャネルに対応する符号化情報、及び、１つ以上の第２のデータパケット内に前記第２の左チャネル、第２の右チャネル、センターチャネル、及び重低音効果チャネルに対応する符号化情報を含み、
前記１つ以上の第１のデータパケットはさらに、前記１つ以上の前フレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、センターチャネル、及び重低音効果チャネルの組み合わせに対応する前記第２のビットレートでの符号化情報を含む１つ以上の符号化ＦＥＣフレームを含み、
前記所定のソースフレームに対応する前記再構築フレームを生成することは、前記所定のソースフレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、センターチャネル、及び重低音効果チャネルに対応する欠落情報を、前記第１のデータパケットのうちの１つ以上のデータパケットにおける前記所定のソースフレームの前記第１の左チャネル、第１の右チャネル、第２の左チャネル、第２の右チャネル、センターチャネル、及び重低音効果チャネルの前記組み合わせに対応する前記情報から引き出すことを含む、請求項２５に記載の方法。
【請求項５１】
プロセッサモジュールと、
前記プロセッサに接続されたメモリと、
を備えるシステムであって、前記メモリは、１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームを含むデータパケットを復号化し再構築する方法を実施するように構成された実行可能命令を含み、前記方法は、
複数のデータパケットを受信することであって、前記複数のデータパケットのいくつかのデータパケットは、第１のビットレートで符号化されたシーケンス内のソースフレームと、前記第１のビットレート以下の第２のビットレートでＦＥＣフレームとして符号化された前記シーケンス内の１つ以上の前フレームとに対応する符号化情報を含み、前記１つ以上の符号化ソースフレームの内の一つの符号化ソースフレームに対する情報の一部を前記１つ以上の符号化ＦＥＣフレームとともに第１のパケットに入れ、前記一つの符号化ソースフレームに対する情報の残りを第２のパケットに入れることにより、前記１つ以上の符号化ソースフレーム及び前記１つ以上の符号化ＦＥＣフレームは、１つ以上のデータパケットにパケット化され、前記第２のパケットには前記符号化ＦＥＣフレームが全く含まれないが、前記第１のパケットに含まれる前記符号化ＦＥＣフレームにおける情報が、前記第１のパケットおよび前記第２のパケットにおける前記一つの符号化ソースフレームに対する情報を再構築するのに十分である、前記複数のデータパケットを受信することと、
前記複数のデータパケットの前記データパケットから、前記１つ以上の符号化ソースフレーム及び前記１つ以上の前フレームに対応する前記符号化情報を、パッケージ解除することと、
前記１つ以上の符号化ソースフレームを復号化して、１つ以上の復号化ソースフレームを生成することと、
前記シーケンスの所定のソースフレームに対応する符号化情報が前記複数のデータパケットから欠けているか否かを判定することと、
前記所定のソースフレームに対応する、前記複数のデータパケット内の１つ以上の対応符号化ＦＥＣフレームを識別することと、
前記１つ以上の対応符号化ＦＥＣフレームを復号化して、１つ以上の復号化ＦＥＣフレームを生成することと、
前記１つ以上の復号化ＦＥＣフレームを使用して、前記所定のソースフレームに対応する再構築フレームを生成することと
を含む、システム。
【請求項５２】
１つ以上の符号化ソースフレーム及び１つ以上の符号化前方誤り訂正（ＦＥＣ）フレームを含むデータパケットを復号化し再構築する方法を実施するように構成されたコンピュータ可読命令を包含する非一時的コンピュータ可読記録媒体であって、前記方法は、
複数のデータパケットを受信することであって、前記複数のデータパケットのいくつかのデータパケットは、第１のビットレートで符号化されたシーケンス内のソースフレームと、前記第１のビットレート以下の第２のビットレートでＦＥＣフレームとして符号化された前記シーケンス内の１つ以上の前フレームとに対応する符号化情報を含み、前記１つ以上の符号化ソースフレームの内の一つの符号化ソースフレームに対する情報の一部を前記１つ以上の符号化ＦＥＣフレームとともに第１のパケットに入れ、前記一つの符号化ソースフレームに対する情報の残りを第２のパケットに入れることにより、前記１つ以上の符号化ソースフレーム及び前記１つ以上の符号化ＦＥＣフレームは、１つ以上のデータパケットにパケット化され、前記第２のパケットには前記符号化ＦＥＣフレームが全く含まれないが、前記第１のパケットに含まれる前記符号化ＦＥＣフレームにおける情報が、前記第１のパケットおよび前記第２のパケットにおける前記一つの符号化ソースフレームに対する情報を再構築するのに十分である、前記複数のデータパケットを受信することと、
前記複数のデータパケットの前記データパケットから、前記１つ以上の符号化ソースフレーム及び前記１つ以上の前フレームに対応する前記符号化情報を、パッケージ解除することと、
前記１つ以上の符号化ソースフレームを復号化して、１つ以上の復号化ソースフレームを生成することと、
前記シーケンスの所定のソースフレームに対応する符号化情報が前記複数のデータパケットから欠けているか否かを判定することと、
前記所定のソースフレームに対応する、前記複数のデータパケット内の１つ以上の対応符号化ＦＥＣフレームを識別することと、
前記１つ以上の対応符号化ＦＥＣフレームを復号化して、１つ以上の復号化ＦＥＣフレームを生成することと、
前記１つ以上の復号化ＦＥＣフレームを使用して、前記所定のソースフレームに対応する再構築フレームを生成することと
を含む、非一時的コンピュータ可読記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
［優先権の主張］
本特許請求は、２０１６年８月１日に出願された米国特許出願第１５／２３５，５０８の優先権の利益を主張し、当開示全体は、参照により本明細書に組み込まれるものとする。
【０００２】
本開示は、ネットワークを介したデータ転送に関する。特に、本開示の態様は、パケット交換ネットワークにおいて低信頼トランスポートプロトコルを使用して輻輳制御を行うシステム及び方法に関する。
【背景技術】
【０００３】
デジタルストリーミングサービス及び様々なクラウドベースコンピューティングソリューションの普及が進むにつれて、リモートデバイス間で大量のデータを迅速かつ正確に転送する機能は、重要な役割となっている。インターネット、広域ネットワーク（ＷＡＮ）、またはローカルエリアネットワーク（ＬＡＮ）などのネットワークの共有リソースを通して宛先システムへデジタルデータを送信するには通常、固定長または可変長であり得るパケットと呼ばれるフォーマットされたブロックにデータを配置することを伴う。各データパケットは通常、宛先に配信される基本ユーザデータを有するペイロードすなわち本体、並びに一般にデータパケットのヘッダ内に少なくとも部分的に含まれる、ルーティング及び制御目的で使用される特定の補足情報を含む。概して、ネットワーク、送信システム、及び受信システムは、この補足情報を使用して、目的の宛先へペイロードの適切なルーティング及び配信を確保する。
【０００４】
このようなパケット交換ネットワークを介したデータ転送でしばしば避けられない結果に、パケット損失があり、これは、１つ以上のデータパケットがそれらの宛先に正しく届かなかった時に発生する。パケット損失は、チャネル輻輳、信号劣化、及び他の理由を含む様々な要因により発生し得る。ネットワークチャネル内の利用可能な帯域幅を効率的に使用しながら、パケット損失を引き起こす特定のネットワーク状況を防止するために、様々な誤り訂正技術が開発されてきた。さらに、パケット損失に対処するツールを包含し得る様々なトランスポートプロトコルがあり、パケット損失が発生した時にパケット損失に対処するのに使用される特定の方法は、データ転送中に使用される特定のトランスポートプロトコルに依存する。一般に、これらのトランスポートプロトコルは、高信頼プロトコルと低信頼プロトコルの２種類に分類することができ、それぞれが特定のトレードオフを示し、任意のインスタンスにおいて使用されるプロトコルの具体的な選択は、データ転送の特質に依存し得る。
【０００５】
高信頼プロトコルは、パケット損失のイベントで欠落したパケットを再送して、各データパケットがその宛先に順序通りに配信される保証を包含する。高信頼プロトコルは、必ずではないが多くの場合、コネクション型プロトコルであり、配信保証は通常、特定の通信セッションの受信者から送信者へ戻るバックチャネルを確立することにより達成され、受信者はバックチャネルを使用して、パケットが正しく配信されたことを確認するある種の肯定応答レシートを送信し得る。データパケットがそれらの宛先に正しく届かなかったことが示された場合、送信者は、これらの肯定応答を使用して、再送プロセスに誘導し得る。高信頼プロトコルの普及している有名な例としては、伝送制御プロトコル（ＴＣＰ）があり、これもコネクション型である。テキストベースの電子メールの送信、デジタルコンテンツのダウンロード、及び宛先のシステムで音声／映像をバッファリング可能なメディアストリーミングサービスなど、データの正確な転送が一番の懸念事項であり、データパケットが正しく配信されたことを確認するためにある程度の遅延は許容され得るタスクには、ＴＣＰなどの高信頼プロトコルがよく適している。残念ながら、データ検証特性及びデータの再送は、比較的大きなオーバーヘッドをもたらし、数多くの高信頼プロトコルは、生の音声及び／または映像ストリーミング、オンラインビデオゲーム、並びにインターネット電話などのリアルタイムのデータ転送を含むタイムクリティカルなアプリケーションにとって望ましくないものとなる。
【０００６】
対照的に、低信頼プロトコルは、一般に、前述のような特定のパケットに対するデータ配信確認の類はなしで済ませ、一般に、各パケットがその宛先に届くことを保証しない、並びにパケットが正しい順序で配信されることを確保しないことを特徴とする。低信頼プロトコルは、必ずではないが多くの場合、コネクションレス型であり、通常はいずれの特定の通信セッション中も固定チャネルを確立しない。各データパケットは代わりに、各データパケットに含まれる補足情報に基づいて、独立にルーティングされ得る。低信頼プロトコルの普及している有名な例としては、ユーザデータグラムプロトコル（ＵＤＰ）があり、これもコネクションレス型である。ＵＤＰのような低信頼プロトコルは、上記の信頼性特性を免除することによりオーバーヘッドを比較的低減させたことから、これらのプロトコルは、上記のリアルタイムアプリケーションのような待ち時間の最小化が一番の懸念事項である時間制約付きアプリケーションにより適している。
【０００７】
低信頼プロトコルは一般に、データパケットの再送を差し控えることから、低信頼サービスを使用してデータを転送する場合には、パケット損失に対処するために前方誤り訂正（ＦＥＣ）として知られる技術が一般的に使用される。ＦＥＣは、適切に配信されなかったソースパケットを送信者が再送する必要なしに、失われたデータを独立的に再構築する能力を、受信者デバイスに提供する。前方誤り訂正が使用される場合、元のソースデータは通常、ＦＥＣパケットの形態で送信者側において冗長的に符号化され、ソースパケットと同時に受信者へ送信される。ソースパケット損失のイベント発生時、受信者デバイスは、再送を待つ必要なしに、ＦＥＣパケットに含まれる冗長符号化データを利用して、損失データを再構築し得る。
【０００８】
損失の種類の中でも、ＷｉＦｉ（登録商標）などの低信頼のプロトコル及び接続は、約５０ミリ秒の期間接続が失われる、いわゆるバースト性損失に、特に脆弱である。前方誤り訂正の既存の方法は、リードソロモンＦＥＣを含み、この方法では、所定のソースフレームの２つのリードソロモン符号化版が、送信されるソースフレームの１０ミリ秒以内のＦＥＣフレームとして送信される。リードソロモン符号化により、同じ解像度で元のソースフレームの再構築が可能となる。しかしながら、接続損失が１０ミリ秒以上続いた場合、ソースフレーム及びＦＥＣフレームの両方が失われ得る。ソースフレームまたはＦＥＣフレームのいずれかが失われても中断は発生しないが、両方とも失われると再構築は不可能となる。従って、先の方法は、非常に短時間の接続損失を訂正するのに役立ち得るが、より長いバースト性中断に対処できる誤り訂正が求められている。
【０００９】
重要なことには、ネットワーク状態は多くの場合経時的に変化し、ネットワークチャネルを介して送信者が利用可能な最大ビットレートが、チャネル上の現在の負荷に基づいて変わる原因となる。送信者システムがチャネルの現在利用可能な帯域幅を超えるビットレートでデータパケットを送信しようとする場合、それに応じて、深刻なパケット損失を引き起こす輻輳状態が起こり得る。ＴＣＰなどの高信頼データ転送を伴う時間制約の低いアプリケーションでは、損失データの再送が保証されているため、これは許容され得る。しかしながら、数多くのリアルタイムアプリケーション及び低信頼転送を伴う他のアプリケーションでは、パケット損失が受信者により損失データを再構築できない程度である場合もあり、これにより信号のドロップアウトなどの望ましくない結果が生じるため、これは受容され得ない。一方、代わりに最大利用可能ビットレートが送信者により提供されるビットレートをはるかに超える場合、ネットワークチャネルの全伝送能力が非効率的に利用され、結果的に受信者側の信号品質が不必要に劣り得るため、この状況も望ましくはない。従って、誤り訂正は、帯域幅容量を超えるほど多くの誤り訂正パケットにより新たなパケット損失を生み出すことなく、パケット損失の有効な補償率を確保するために、ネットワーク状態に動的に適応できなければならない。
【００１０】
残念ながら、容認できないパケット損失をもたらす輻輳状態を引き起こすことなく、ネットワークチャネルの利用可能な帯域幅を効率的に利用するように、低信頼プロトコルを使用してデータを転送することは、相当な課題である。従来の輻輳制御技術は、多くの場合、トランスポート層に組み込まれた送信者へのフィードバックを有するＴＣＰなどの高信頼プロトコルにのみ適しているが、ユーザによりトランスポート層を介して独立的に追加されない限り必要なフィードバックに通常欠けるＵＤＰなどの多数の低信頼プロトコルには、効果がない。さらに、輻輳点に至るビットレートの増加から生じるパケット損失は、ＴＣＰまたは他の高信頼プロトコルを使用してデータを再送する時間制約の低いアプリケーションでは許容され得るが、数多くのリアルタイムアプリケーションでは、受信者がデータを再構築できなくなるため、受容され得ない。
【００１１】
従って、当技術分野では、ＵＤＰ、並びに周期的及びバースト性損失を経験する他の低信頼トランスポートプロトコルと共に使用するのに適した、動的な前方誤り訂正、並びに効率的な輻輳制御及び輻輳回避技術が求められている。本開示の態様は、このような観点から生じる。
【発明の概要】
【００１２】
本開示の特定の実施態様によれば、フレームを符号化し送信する方法は、シーケンス内の現フレーム及びシーケンス内の１つ以上の前フレームを含む複数の未符号化フレームを受信することまたは生成することを含み得る。現フレームは第１のビットレートで符号化され、１つ以上の符号化ソースフレームが生成される。１つ以上の前フレームは、第１のビットレート以下の第２のビットレートで符号化され、１つ以上の符号化ＦＥＣフレームが生成される。１つ以上の符号化ソースフレーム及び１つ以上の符号化ＦＥＣフレームは、１つ以上のデータパケットにパケット化され、これらはメモリに格納され得る、またはデータネットワークを介して送信され得る。１つ以上のデータパケットは、符号化ＦＥＣデータを含まないいくつかのパケットを含み得るデータパケットのストリームの一部であり得る。
【００１３】
本開示の特定の実施態様によれば、送信者コンピューティングシステムは、少なくとも１つのプロセッサユニットと、少なくとも１つのプロセッサユニットに接続された少なくとも１つのメモリユニットとを含み得る。少なくとも１つのプロセッサユニット及び少なくとも１つのメモリユニットは、前述の符号化及び送信方法を実行するように構成され得る。
【００１４】
本開示の特定の実施態様によれば、非一時的コンピュータ可読媒体は、コンピュータ可読命令を包含し得る。コンピュータ可読命令は、実行された場合、前述の符号化及び送信方法を実施するように構成され得る。
【００１５】
本開示の特定の実施態様によれば、データパケットの復号化及び再構築方法は、複数のデータパケットを受信することを含むことができ、複数のデータパケットはそれぞれ、第１のビットレートで符号化されたシーケンス内のソースフレームと、第１のビットレート以下の第２のビットレートで前方誤り訂正（ＦＥＣ）フレームとして符号化されたシーケンス内の１つ以上の前フレームとに対応する符号化情報を含む。ソースフレーム（複数可）及び１つ以上の前フレーム（複数可）に対応する符号化情報は、複数のデータパケットそれぞれからパッケージ解除される。１つ以上の符号化ソースフレームは復号化され、１つ以上の復号化ソースフレームが生成される。シーケンスの所定のソースフレームに対応する符号化情報が複数のデータパケットから欠けているか否かに関して、判定が行われる。所定のソースフレームに対応する、複数のデータパケット内の１つ以上の対応符号化ＦＥＣフレームが識別され、復号化されて、１つ以上の復号化ＦＥＣフレームが生成される。次に１つ以上の復号化ＦＥＣフレームを使用して、所定のソースフレームに対応する再構築フレームが生成される。復号化ソースフレーム（複数可）及び再構築された欠落フレームは次に、メモリに格納され得る、及び／またはディスプレイで順序通りに提示され得る。
【００１６】
本開示の特定の実施態様によれば、受信者コンピューティングシステムは、少なくとも１つのプロセッサユニットと、少なくとも１つのプロセッサユニットに接続された少なくとも１つのメモリユニットとを含み得る。少なくとも１つのプロセッサユニット及び少なくとも１つのメモリユニットは、前述の復号化及び再構築方法を実行するように構成され得る。
【００１７】
本開示の特定の実施態様によれば、非一時的コンピュータ可読媒体は、コンピュータ可読命令を包含し得る。コンピュータ可読命令は、実行された場合、前述の復号化及び再構築方法を実施するように構成され得る。
【図面の簡単な説明】
【００１８】
本開示の教示は、添付図面と合わせて以下の詳細説明を考察することにより、容易に理解され得る。
【００１９】
【図１】本開示の特定の態様による、例示的なデータ転送及び前方誤り訂正技術の概略図である。
【図２】本開示の特定の態様による、例示的な誤り訂正技術のフロー図である。
【図３Ａ】現存する前方誤り訂正方法によるデータパケット構造を例示するブロック図である。
【図３Ｂ】本開示の態様による前方誤り訂正の実施態様に従ったデータパケット構造を例示するブロック図である。
【図４】本開示の特定の態様による、ストリーミングデータ送信における前方誤り訂正の詳しい実施例のフロー図である。
【図５】本開示の特定の態様による、サラウンドサウンド送信の状況で誤り訂正を実施するのに有用なデータパケット構造のブロック図である。
【発明を実施するための形態】
【００２０】
以下の詳細説明は例示目的で多数の具体的な詳細を含むが、いずれの当業者も、以下の詳細に対する多数の変形及び変更が本発明の範囲内であることを理解するであろう。従って、後述される本開示の例示的な実施態様は、特許請求の範囲に記載される本発明に対し、普遍性を損なうことなく、また限定を課すことなく、明記される。
【００２１】
［序説］
本開示の態様は、特別にパッケージ化されたソースフレーム及びＦＥＣ履歴フレームを使用して、バースト性パケット損失を補償することに関し、これはＵＤＰなどの低信頼トランスポートプロトコルと共に使用され得る。特に、ＷＩＦＩ接続はパケット損失のバーストに対して脆弱である。所定の現フレームに対して、前フレームは、より低いビットレートで第２の別個のコーデックにより符号化され、現フレームと共に送信される。これらの前フレームは、ＦＥＣフレームと称される。ＦＥＣフレームに対し低いビットレートを使用することで、パケットを送信するための追加帯域幅要件が軽減される。ソースフレームが失われた場合、ＦＥＣフレームを使用して、ソースフレームが再構築される。再構築または復号化されたＦＥＣフレームはソースフレームよりも低い解像度を有し得るが、再構築の必要性が断続的である場合（例えば音声の事例で、５０ミリ秒未満の間隔での中断）、ソースフレームのビットレートと再構築フレームのビットレートの差異は、人間の知覚の閾値未満である。従って、ＦＥＣフレームが、全体的な知覚品質を低下させることはない。知覚される音声品質または帯域幅要件を変えるために、各ＵＤＰパケット共に送信されるＦＥＣフレームの数及びビットレートを調整することができる。ＵＤＰパケットヘッダは、ソースフレームのビットレート及びシーケンスＩＤ、並びにＦＥＣフレームのビットレート及びＩＤについての関連情報を含み得る。
【００２２】
特定の態様によれば、１つ以上の送信者デバイスは、ＵＤＰなどの低信頼トランスポートプロトコルを使用して１つ以上の受信者デバイスへデータパケットを送信し得る。データパケットは、所望のソースデータを含む符号化ソースフレーム、並びにストリーム内の前のソースパケットのうちの１つ以上が１つ以上の受信者デバイスに届かなかったイベントにおける前方誤り訂正のために、前フレームからのソースデータの冗長性を含む符号化ＦＥＣフレームの両方を含み得る。定期的なフィードバックレポートが、１つ以上の受信者デバイスから１つ以上の送信者デバイスへ送信され得る。フィードバックレポートは、対応期間中のパケット損失を識別することができ、送信者は、フィードバックレポートを使用して、期間中にパケット損失が発生したか否かを特定し得る、及び／または対応期間中のパケット損失の範囲を特定し得る。このようなフィードバックは、バースト性パケット損失のおおよその間隔を特定するのに役立ち得る。
【００２３】
特定の態様によれば、１つ以上の送信者デバイスは、定期的なフィードバックレポートを使用して、１つ以上の受信者デバイスに送信されるストリーム内のデータパケットのビットレートの態様を調整し得る。ビットレートの態様は、受信者デバイスがソースデータを取得する能力を最適化するように、調整され得る。特定の態様では、パケット損失が許容レベル内であることを示すフィードバックレポートに応じて、ＦＥＣパケットのビットレートは増加され得、同時に、初期フィードバックレポートに応じて、ストリーム内のソースパケットの並行ビットレートは維持される。特定の態様によれば、誤り訂正に使用されるＦＥＣパケットの数のみを増加させることによりビットレートは調整され得るため、たとえビットレートの増加が輻輳及びパケット損失の増加をもたらしたとしても、１つ以上の受信者デバイスは、ソースデータを再構築することが可能であり得る。例えば、ソースパケットに対するＦＥＣパケットの比が増加し得るため、配信中のソースパケットの損失により失われたデータを再構築するのに十分な数のＦＥＣパケットが、無事に配信される可能性は高い。
【００２４】
［さらなる詳細説明］
ここで図１を参照すると、本開示の特定の態様による、データ転送及び前方誤り訂正（ＦＥＣ）技術の説明的実施例が示される。図１の実施例では、１つ以上の送信者デバイス１０２は、ネットワーク１０６を介して１つ以上の受信者デバイス１０４へデータを送信することができ、データは、複数のデータパケット１０８の形態で送信され得る。データパケット１０８は、ＵＤＰなどの低信頼プロトコルを使用して送信されるデータグラムであり得、各パケット１０８の配信もパケット１０８の順番通りの配信も、プロトコルにより保証されていない。従って、パケット損失のイベント時、送信者デバイス１０２は失われたパケットを再送せず、むしろ受信者デバイス１０４が、使用される特定のＦＥＣ技術によりデータストリーム内に符号化された冗長性を使用して、失われたソースデータを再構築するように試み得る。
【００２５】
図１に示されるように、データパケット１０８は、受信者デバイス１０４に配信される元のソースデータ１１０を含むソースパケット（図１の斜線ボックス）と、利用可能な他のソースパケットまたはパリティパケットが十分にあるならば任意の失われたソースパケットの代わりとなり得る情報を含むパリティパケットであるＦＥＣパケット（図１の白／空白ボックス）との両方を含み得る。ＦＥＣパケットは、元のソースデータ１１０の冗長性を含むことができ、ソースパケットのうちの１つ以上が、例えばネットワーク１０６で欠落したという理由で、受信者１０４へ正しく届かなかったというイベント発生時には、受信者デバイス１０４はＦＥＣパケットを使用して、ソースデータ１１０を再構築し得る。送信データが音声及び映像ストリームを含む特定の実施態様では、データパケット１０８はさらに、前述の両種類の音声パケット及び映像パケットの両方を含むことができ、例えばデータパケット１０８は、音声ソースパケット、音声ＦＥＣパケット、映像ソースパケット、及び映像ＦＥＣパケットを含むことができ、音声パケットは一般に映像パケットよりも小さくあり得る（すなわちより少ない量のデータを含み得る）。具体的には、音声パケットには、ステレオソースパケット、ステレオＦＥＣパケット、５．１サラウンドサウンドソースパケット、５．１サラウンドサウンドＦＥＣパケット、または他の音声システムの音声パケットも含まれ得る。
【００２６】
特定の実施態様では、ソースデータ１１０は、受信者デバイス１０４へリアルタイムで送信されるデータストリームであり得、ソースデータ１１０は、送信者デバイス１０２上で実行されるアプリケーションにより生成され得る。このような実施態様では、リアルタイムソースデータ１１０は、順次出力されるデータの複数のフレームから構成され得、フレームはソースデータを生成するアプリケーションにより定義され得る。例えば、ソースデータ１１０は、ビデオゲーム、ビデオ電話プログラム、または他の音声／映像（Ａ／Ｖ）ソースプログラムなど、送信者デバイス１０２上で実行されるアプリケーションから出力されるリアルタイムのＡ／Ｖストリームであり得、アプリケーションが各フレームを定義し得る。
【００２７】
図１の実施例では、例示されるソースデータ１１０のブロックは、例えば単一Ａ／Ｖフレームといった単一フレームに対応し得、これに対し、複数のソースパケット及びＦＥＣパケットが生成され、ネットワーク１０６を介して受信者デバイス１０４へ送信される。データのストリームは、送信者デバイス１０２においてシーケンスで生成され得る複数のフレーム１１０から構成され得、受信者デバイス１０４へ送信するために、フレームごとに複数のデータパケット１０８が形成され得る。
【００２８】
ＵＤＰまたは別の低信頼プロトコルを使用してデータが送信される場合、データパケット１０８、例えばデータグラムは、ネットワーク１０６により異なるそれぞれの経路を介してルーティングされ得、順序関係なく受信者デバイスに到着し得ることに留意されたい。受信者デバイス１０４におけるデータの再構築を容易にするために、データパケット１０８のそれぞれは、送信者デバイスにより特定の識別情報でスタンプされてもよい。例えば、各データパケット１０８は、シーケンスにおいてどのフレームにデータパケットが属するかを示す、例えばフレーム番号といったフレーム識別子、並びに各フレーム内で（及び／または複数のフレームにわたって）シーケンスにおけるどの場所にデータパケットが属するかを示す、例えばシーケンス番号といったシーケンス識別子で、スタンプされてもよい。従って、送信者デバイス１０２は、形成された新たなデータパケットごとにシーケンス番号を増分し得、形成された新たなフレームごとに、データパケットのフレーム番号を増分し得る。任意で、データストリームが音声成分及び映像成分の両方を有するリアルタイムデータストリームである実施態様において、データパケット１０８は、例えばパケットが音声パケットであるかまたは映像パケットであるかを識別する種類識別子などのさらなる識別情報でも、スタンプされてもよい。データパケット１０８はまた、例えばソースフレームのビットレート、ＦＥＣフレームのビットレート、ペイロード内のどの符号化フレームがソースフレームに対応し、ペイロード内のどの符号化フレームがＦＥＣフレームに対応するかなど、フレームの特性に関する情報といったメタデータを含み得る。このようなメタデータは、データパケット１０８のヘッダに含まれ得る。受信者デバイス１０４は、各パケットにスタンプされたこの補足情報に従って、データを組み立てることができ、従って、例えば受信者側のエンドユーザに提示するようにデータを復号化することができる。
【００２９】
図１に示されるように、ソースパケットのうちの１つ以上がネットワーク１０６で欠落した、あるいはそれらの宛先に届かなかったというパケット損失のイベント発生時、受信者デバイス１０４は、送信者デバイス１０２による再送なしに、冗長符号化ＦＥＣパリティパケットを利用して、ソースデータ１１０を再構築し得る。異なるアルゴリズムを使用して、１つ以上のソースパケットから任意の数のＦＥＣパリティパケットを生成することができることに留意されたい。特定の実施態様では、ＦＥＣデータは、消去コードを使用して生成され得る。特定の実施態様では、誤り訂正スキームは、受信者に届かなかったソースパケットごとに、特定のデータセットを再構築するのに１つのＦＥＣパケットを必要とし得るものであり得る。例えば、受信デバイスに配信されたデータの特定のフレームに関して、ＦＥＣ技術は、パケット損失のイベント発生時にフレームを完全に再構築するために、受信デバイスに正しく届いたＦＥＣパケットの数が、失われたソースパケットの数と少なくとも等しくある必要があるものであり得る。等しくない場合、フレームは破損したものになり得る。言い換えると、Ｎ個のソースパケットが存在し、Ｍ個のパリティパケットが生成された場合では、全部で少なくともＮ個のパケット（ソース及びパリティ）が受信されると、ソースデータを回復することができる。図１の例示では、送信者により送信されたソースパケットの数は、送信されたＦＥＣパケットの数に等しい、すなわち、例示を簡潔にすると、送信者１０２により送信されたＦＥＣパケットに対するソースパケットの比は、単純に１：１である。しかしながら、後述されるように、数多くの他の比が使用されてもよいこと、及び本開示の特定の態様に従って、ＦＥＣパケットに対するソースパケットの比は動的であり、ストリーム中に経時的に変化してもよいことに、留意されたい。
【００３０】
データ転送中に利用可能な帯域幅を効率的に利用する方法を最適化するため、並びに許容できないパケット損失を引き起こすようなやり方でネットワークチャネルに負荷をかけ過ぎることを避けるために、送信者デバイス１０２及び／または受信者デバイス１０４は、本開示の態様による輻輳制御アルゴリズムを実施するように構成され得る。
【００３１】
図２は、送信者２０１での発生から始まり、ネットワーク２０２を介して受信者２０３に至る、本開示の態様による前方誤り訂正の全体的なプロセスフローの一実施例を示す。まず送信者側２０１で、ソースフレーム生成器２１２及びＦＥＣフレーム生成器２１４がそれぞれ、ソースフレーム２２２及びＦＥＣフレーム２２４の１つまたは集合を作成する。様々な実施態様では、ソースフレーム２２２及びＦＥＣフレーム２２４に符号化される予定のデータには、音声データ、映像データ、ゲームシステムの制御入力ストリーム、または送信もしくは格納される必要のあり得る他のデータシーケンスが含まれ得る。より具体的には、フレームは、音声ソースデータ、音声ＦＥＣデータ、映像ソースデータ、及び映像ＦＥＣデータを含むことができ、音声データは一般に映像データよりも小さくあり得る（すなわちより少ない量のデータを含み得る）。さらに、音声データには、ステレオソースデータ、ステレオＦＥＣデータ、５．１サラウンドサウンドソースデータ、５．１サラウンドサウンドＦＥＣデータ、または他の音声システムの音声データが含まれ得る。
【００３２】
次に、２２６に示されるように、ソースフレーム２２２及びＦＥＣフレーム２２４が符号化される。限定ではなく例示として、送信者側２０１のコンピュータシステムは、同じコーデックの２つのインスタンスを実施して、ソースフレーム２２２及びＦＥＣフレーム２２４を符号化し得る。ソースフレーム及びＦＥＣフレームをそれぞれ生成するため、または復号化されたものをそれぞれ生成するために、２つの別個のハードウェアコーデック、２つの別個のソフトウェアコーデック、ハードウェアコーデック及びソフトウェアコーデックの組み合わせを使用して、本開示を実施することもできる。さらに、これらの教示と一致する、当業者が生み出し得るコーデックのさらなる組み合わせが存在し得る。
【００３３】
２２６における符号化プロセスは、ソースフレーム２２２を、ＦＥＣフレーム２２４よりも高いビットレートで符号化する。ＦＥＣフレームに対しより小さいビットレートを使用することにより、符号化ソースフレーム及び符号化ＦＥＣフレームを送信するために使用するデータ量が低減される。ＦＥＣフレーム符号化ビットレートに対するソースフレーム符号化ビットレートの比は、受信側における復号化フレームの最低許容品質に依存する。例えば、ソースビットレートが６４ｋｂｐｓであり、コンテンツが低品質の発話である場合、ＦＥＣビットレートは１６ｋｂｐｓに低下し得る。同じ事例でソースビットレートが１２８ｋｂｐｓである場合、ＦＥＣビットレートは依然として１６ｋｂｐｓであり得、比は８：１となる。限定ではなく例示として、ＦＥＣフレームビットレートに対するソースフレームビットレートの比は、約１から約１０の間、または約１．５から約８の間であり得る。他の比も可能であり、本開示の教示の範囲内である。
【００３４】
次に、送信者システム２０１は、符号化ソースフレーム及び符号化ＦＥＣフレームを、ネットワーク２０２を介して送信するために、符号化フレームを１つ以上のデータパケット２４０にパケット化するパケット化プロセス２３０にかける。１つ以上のデータパケット２４０は、１つ以上のソースフレーム２２２及び１つ以上のＦＥＣフレーム２２４に対応した符号化データを含む。特定の実施態様では、データパケットは、ユニフォームデータグラムプロトコル（ＵＤＰ）パケットであり得る。開示される要素を実施するのに当業者が利用できる他のパケット化プロトコルにも、開示される本発明は適用される。さらに、データパケット２４０の特定の実施態様は、受信したパケット２４０を受信者が正しく順序付けることを可能にする識別情報をさらに含み得る。識別情報は、ペイロード内の符号化ソースフレームまたは符号化ＦＥＣフレームのシーケンス識別子または番号、所定のデータパケットのペイロード内の符号化ＦＥＣフレームの番号、ソースフレームのビットレート、ＦＥＣフレームのビットレート、ソースフレームに対応するペイロード内の符号化フレーム（複数可）の識別情報、またはＦＥＣフレームに対応するペイロード内の符号化フレーム（複数可）の識別情報を含み得るが、これらに限定されない。さらに、この識別情報は、パケット２４０のヘッダに配置され得る。さらに、当業者は、本開示の教示に一致する、フレームの順序を特定する別の識別スキームを使用することができる。
【００３５】
ソースフレームコーデックのビットレートは、ＦＥＣフレーム生成器コーデックのビットレートよりも高くあり得る。音声の特定の事例では、ソースフレームコーデックを毎秒６４キロビットのビットレートで作動させ、一方、ＦＥＣフレームコーデックを毎秒１６キロビットのビットレートで作動させることができる。これにより、およそ４つのＦＥＣフレームが、１つのソースフレームと同じデータ量をパケット内で占めることが可能になる。さらに、特定の実施態様では、様々な期間のバースト性損失を補償するために、データパケット２４０内のソースフレームごとにパケット化されたＦＥＣフレームのビットレート及び数が、動的に調整され得る。ＦＥＣフレームの数の動的な調整を実施する１つの特定の方法は、所定のパケットに追加されるＦＥＣフレームの数を、バースト性損失期間により失われたフレームを補償するために必要なフレームの数と一致させることである。フィードバックは、受信者２０３から送信者２０１へ返される返却パケットの形態で届き得る。
【００３６】
限定ではなく例示として、受信者システム２０３は、受信したパケット内のパケットシーケンスメタデータを分析して、損失したパケットを特定し、パケット損失を時間の関数として追跡し得る。バースト性パケット損失は、比較的短期間であるが大体一定の時間間隔で発生するパケット損失の急激な増加に基づいて、特定され得る。受信者システムは、ある時間窓にわたりパケット損失データを集約し、パケット損失の急上昇の事象間の平均間隔及び／またはそのような急上昇の継続時間を特定し、そのような情報を送信者システム２０１に返信し得る。次いで送信者システムは、平均パケット損失情報を使用して、ソースフレーム２１２及びＦＥＣフレーム２１４を符号化するためのビットレートを調整し得る。送信者はまたこの情報を使用して、データパケット２４０において、ソースフレームごとにパケット化されるＦＥＣフレームの数を調整し得る。
【００３７】
バースト性損失の長さは、受信者側でソースフレームのシーケンス番号を調べることにより、検出され得る。番号の実施例として、ソースフレームＮ及びソースフレームＮ＋４が受信されたが、その間は受信されなかった場合、バースト性損失の長さは、３フレームであり、各フレームが１０ミリ秒である場合、３０ミリ秒である。上記のように、受信者システム２０３は、ある時間窓にわたりバースト性損失継続時間を平均化し、当時間窓に関して特定された平均バースト性損失継続時間を、送信者システム２０１へ返信し得る。これに応じて、送信者システムは次に、ソースフレーム及びＦＥＣフレームの符号化ビットレートを調整し得る。ビットレートはまた、ＦＥＣフレームの利用可能な総帯域幅及び所望数に基づいて調整されてもよい。例えば、送信者２０１と受信者２０３との間でＦＥＣフレームに利用可能な帯域幅が２００ｋｂｐｓ存在し、ＦＥＣフレームの所望数が４から５に変化した場合、送信者は、ＦＥＣフレームを符号化するビットレートを、５０ｋｂｐｓから４０ｋｂｐｓに変更し得る。
【００３８】
パケット２４０は、ネットワーク２０２を介して送信される前に、一時的にメモリバッファ２４５に格納され得る。図２はネットワーク２０２を介した符号化データの送信を具体的に示しているが、パケット２４０が、送信されるのではなく、ハードドライブ、ＣＤ、フラッシュドライブ、またはメモリの他の形態など、一時的バッファ２４５以外のメモリのある形態に格納される実施態様も、本開示に包含される。データパケット２４０がメモリに格納され、かつネットワーク２０２を介して送信される実施態様も、本開示に包含される。
【００３９】
ネットワーク２０２を介した送信は、ＷｉＦｉを含む無線通信の任意の形態を含み得る。図１に示されるように、ネットワーク２０２を介した送信は、周期的に信頼性が低くなり得るため、送信された全てのパケット２４０がその後受信者２０３に届き得るとは限らない。特に、無線通信は、シーケンス内の複数のパケットが失われるバースト性損失を起こしやすくあり得る。この損失は、約５０ミリ秒の送信中断を表す。本開示の別の箇所で論じられたように、既存の前方誤り訂正方法は、リードソロモン訂正を含み、これはバースト性損失の発生中はさほど頑強ではない。
【００４０】
パケットは、受信者２０３に届くと、２５０に示されるように、符号化ソースフレームデータ２６２及び符号化ＦＥＣフレームデータ２６４にパッケージ解除され得る。本開示の態様では、符号化フレームデータ２６２及び２６４は、パッケージ解除プロセス２７０を受け得る。このパッケージ解除プロセス２７０では、フレームデータは分析され、前に受信されたフレームのキュー２９０と比較され、シーケンス内のいずれかのフレームが欠けていないかが特定される。フレームが欠けているか否かは、既知の、もしくは特定可能なシーケンス番号、または各フレームに対応付けられたその他の識別情報を調べることにより、判定され得る。識別情報は次いで、キュー２９０内のフレームの位置を特定するために使用され得る。これは、識別特徴またはシーケンス番号を、キュー２９０内に既に存在するフレームと比較することにより、実施することができる。さらに、当業者は、本開示の教示に一致する、フレームの順序を特定する別の識別スキームを使用することができる。
【００４１】
受信されたソースフレームデータ２６２及び／またはＦＥＣフレームデータ２６４は、復号化／再構築プロセス２７４中に復号化され得る。キュー２９０の欠けている任意のソースフレームは、復号化／再構築プロセス２７４により、復号化されたＦＥＣフレームデータ２６４から再構築され得る。一般に、ソースフレームデータ２６２は、再パッケージ後すぐに復号化され、出力フレーム２８０としてキュー２９０に追加される。しかしながら、各受信パケット２４０内のＦＥＣフレームデータをすぐに復号化する必要はない。代わりに、必要に応じて欠けているソースフレームを再構築するのに適した１つ以上のＦＥＣフレームを提供するように、符号化ＦＥＣフレームデータは、バッファ内に格納され、必要に応じて復号化されてもよい。あるいは、ＦＥＣフレームデータ２６４は、パッケージ解除された後に復号化され、結果得られるＦＥＣフレームは、必要となるまでバッファ内に格納されてもよい。対応ソースフレームが受信され復号化されると、受信者システムは、バッファからＦＥＣフレームを削除し得る。欠けている対応ソースフレームと置き換えるために、ＦＥＣフレームは、出力フレーム２８０としてキュー２９０に追加されてもよい。次いで出力フレーム２８０は、キュー２９０から出力２９５として送信され、例えば、メモリ内に格納される、及び／または音声もしくは映像表示などの出力デバイスにより提示される、あるいは、例えばビデオゲームなどのアプリケーションの制御入力として使用される。ＦＥＣフレームデータは、必要な時にのみ復号化され、すなわち受信された全てのＦＥＣフレームが復号化される必要はないことに留意されたい。
【００４２】
本開示の別の場所で述べられたように、図２に示される実施態様は、符号化されていない映像データのストリームに適用することができる。一般に、映像フレームは、Ｉフレーム、Ｐフレーム、及びＢフレームの３種類のうちの１つに圧縮され得る。Ｉフレーム、すなわちイントラ符号化ピクチャは、圧縮性の最も低い完全指定フレームである。Ｐフレーム、すなわち予測ピクチャは、前のフレームからの変化に関する情報を含む。最後に、Ｂフレーム、すなわち双予測ピクチャは、フレーム間の変化に関する情報を含む。後者の２種類のフレームは、他の種類のフレームが復号化されることを必要とする。開示される本発明は、映像誤り訂正の実施態様では、映像ストリームが最小の帯域幅制約、最小のＩフレーム損失、比較的低いフレーム間移動を有し、バースト性損失を被った時に、特に効果的である。
【００４３】
さらに、図２に示される方法は、ゲームの入力ストリームにも適用することができる。具体的には、開示される本発明の実施態様は、符号化されたゲームインターフェース入力ストリームに、バースト性損失からの頑強な保護を提供する。当業者は、バースト性損失を経験し得る低信頼ネットワークを介した他のデータストリームの適用において、開示される本発明の方法を具現化することができる。
【００４４】
図３Ａ〜３Ｂは、既存の前方誤り訂正を、本明細書において開示されるものと比較する。リードソロモンとして知られている既存の前方誤り訂正スキーム３０１では、図３Ａに示されるように構成されたいくつかのパケットが、受信者へ送信される。まず、ＩＰヘッダ３１２、ＵＤＰヘッダ３１４、及びコンテンツのフレームに対応するバイトデータペイロード３１６を含むパケット３１０が、ネットワークを介して受信者へ送信される。示される実施例では、ＩＰヘッダ及びＵＤＰヘッダは共同でパケットの２８バイトを占め、ペイロードは８０バイトを占める。ソースパケット３１０が送信された直後、例えばソースパケット３１０が送信されてから１０ミリ秒以内に、同一の２つのＦＥＣパケット３２０及び３３０が、受信者へ送信される。ＦＥＣパケット３２０、３３０は、ＩＰヘッダ３２２、３３２、ＵＤＰヘッダ３２４、３３４、及びペイロード３２６、３３６をそれぞれ含む。示される実施例では、ＩＰヘッダ３２２、３３２及びＵＤＰヘッダ３２４、３３４は、ＦＥＣパケット３２０、３３０の２８バイトを占め、ペイロード３２６、３３６は、ＦＥＣパケット３２０、３３０の８０バイトを占める。受信者がソースパケット３１０を取得しなかった場合、フレームは、ＦＥＣパケット３２０または３３０により置き換えられ得る。このスキームでは、フレームの処理及び再構築のために、３つの別個のパケットが受信者へ送信される。
【００４５】
図３Ｂは、本開示の態様による前方誤り訂正スキーム３５１を例示する。前方誤り訂正スキーム３５１は、ステレオ音声伝送において特に有用である。このスキームによれば、データパケット３５０は、ＩＰヘッダ３５２と、ＵＤＰヘッダ３５４と、第１のビットレートで符号化された、シーケンスの現フレームＮに対応する符号化情報３５６とを含む。ＵＤＰヘッダ３５４とペイロード（現フレームＮの符号化情報）との間に示される追加のヘッダ３５５は、フレーム番号、並びにソース符号化ビットレート及びＦＥＣ符号化ビットレートに関する情報を含み得る。データパケット３５０はまた、シーケンスの前フレームＮ‐１、Ｎ‐２、Ｎ‐３、Ｎ‐４、Ｎ‐５に対応する符号化情報３５８を含む。前フレームは、第１のビットレートよりも低い第２のビットレートで符号化される。
【００４６】
前方誤り訂正スキーム３５１は、ソースフレームＮ及びＦＥＣフレームＮ‐１、Ｎ‐２、Ｎ‐３、Ｎ‐４、Ｎ‐５内の時間間隔が増加するようなバースト性損失（約５０ミリ秒）の事例において、より優れた頑強性を有し、これは、シーケンス内の所定のフレームが再生可能であることを保証しながらも、接続における大きな欠落を許容できることを意味する。さらに、送信者２０１、ネットワークもしくはメモリストレージ２０２、または受信者２０３が処理できるパケットの数に限界がある場合、スキーム３５１は、より少ないデータパケットを使用して、誤り訂正を提供し得る。図３Ｂに示される実施例では、全体３６３バイトに対し、ヘッダ３５２、３５４は合計２８バイトを占め、符号化ソースフレーム情報３５６は８０バイトを占め、符号化ＦＥＣフレーム情報３５８は２５５バイト（各ＦＥＣフレームが５１バイト）を占める。これは、リードソロモン前方誤り訂正スキーム３０１が必要とする３２４バイトのデータと同様である。この特定の実施例では、パケット３５０内のフレームあたりのＦＥＣフレームデータに対するソースフレームデータの比は、約１．５７である。
【００４７】
図４は、本開示の態様による全体的なプロセスフローの実施態様の特定の実施例を示す。高ビットレートコーデック４１２及び低ビットレートコーデック４１４を使用して、ソースフレーム４２６及びＦＥＣフレーム４２８の集合が生成される。ソースフレーム生成器４１２及びＦＥＣフレーム生成器４１４を特に参照すると、本開示は、同じコーデックの２つのインスタンスを実施して、ソースフレーム及びＦＥＣフレームを対応するソースフレームデータ４２６及びＦＥＣフレームデータ４２８に符号化し得る。ソースフレーム及びＦＥＣフレームをそれぞれ生成するため、または復号化されたものをそれぞれ生成するために、２つの別個のハードウェアコーデック、２つの別個のソフトウェアコーデック、ハードウェアコーデック及びソフトウェアコーデックの組み合わせを使用して、本開示を実施することもできる。さらに、これらの教示と一致する、当業者が作り得るコーデックのさらなる組み合わせが存在し得る。
【００４８】
符号化フレームデータ４２６、４２８は、符号化フレームデータに加えてＩＰ識別ヘッダ４２２及びＵＤＰヘッダ４２４を含むデータパケット４２０にパッケージ化される。パケット４２０は、ネットワーク４０２を介して送信される。ＵＤＰヘッダ４２４とペイロード（現フレームＮの符号化情報）との間に示される追加のヘッダ４２５は、フレーム番号、並びにソース符号化ビットレート及びＦＥＣ符号化ビットレートに関する情報を含み得る。図４はネットワーク２０２を介した符号化データの送信を具体的に示しているが、パケット４２０が、送信されるのではなく、ハードドライブ、ＣＤ、フラッシュドライブ、またはメモリの他の形態など、メモリのある形態に格納される実施態様も、本開示に包含される。データパケット４２０が、例えば一時的メモリバッファ、またはハードドライブ、ＣＤ、もしくはフラッシュドライブなどの永続的記憶媒体といったメモリに格納され、かつネットワーク２０２を介して送信される実施態様も、本開示に包含される。
【００４９】
ネットワーク４０２を介した送信は、ＷｉＦｉを含む無線通信の任意の形態を含み得る。図１に関連して論述されたように、ネットワーク４０２を介した送信は、周期的に信頼性が低くなり得るため、送信された全てのパケット４２０がその後受信者４０３に届き得るとは限らない。特に、無線通信は、シーケンス内の複数のパケットが失われるバースト性損失を起こしやすくあり得る。この損失は、例えば約５０ミリ秒の送信中断を伴い得る。本開示の別の箇所で論じられたように、既存の前方誤り訂正方法は、バースト性損失の発生中はさほど頑強ではない。
【００５０】
受信者は、受信に成功すると、４３０に示されるように、データパケット４２０を調べて、欠けているフレーム４７４に関するデータを含むか否かを判定する。この特定の実施態様では、どのフレーム（複数可）が欠けているかに関する情報は、出力フレームキュー４７０を調べることで特定され得る。例えば、各フレームは、そのヘッダ内に、シーケンス内のフレーム位置を特定するシーケンス情報を有し得る。受信者は、キュー４７０内の各フレームのシーケンス情報を調べることで、欠落が存在するのであれば、どのフレーム（複数可）が欠けているのかを特定し得る。受信者側のコーデック４４０は、データパケット４２０を復号化する。この特定の実施例では、復号化されたソースフレーム４５６は、無事に受信され、よって出力フレームキュー４７０に追加される。復号化ＦＥＣフレーム４５８、及び特にフレームキュー内の欠落フレーム４７４に対応付けられたＦＥＣフレーム４５９は、フレーム再構築プロセス４６０にかけられ、新たな出力フレームが生成され、その後キュー４７０に追加される。最終的に、キュー４７０内の出力フレームは、例えば、音声フレームの場合はスピーカ、または映像フレームの場合は表示装置といった出力デバイスでの提示による出力４８０へ送信される。
【００５１】
図５は、具体的には、ドルビー５．１サラウンドサウンドなどのサラウンドサウンド音声に本開示の態様を適用するためのパケット構造の一実施態様を例示する。ドルビーサラウンドサウンドのフレーム情報には、フロント左（ＦＬ）、フロント右（ＦＲ）、サラウンド左（ＳＬ）、サラウンド右（ＳＲ）、センター（Ｃ）、及び重低音効果（ＬＦＥ）の６つの別個のチャネルの情報が含まれる。図５に示される実施態様によれば、ＦＬ及びＦＲチャネルは最も重要なチャネルとみなされ、ソースフレームデータ及びＦＥＣフレームデータのパッケージ化は、これを考慮するように構成される。しかしながら、図５の実施態様の教示は、複数のチャンネルを有する他のサウンドシステムにも適用できることに留意されたい。
【００５２】
ドルビー５．１サラウンドサウンドシステムの音声に対応付けられたフレーム５１０の場合、フレームのデータは、２つの別個のパケット５２０及び５３０に分割され、これらはほぼ同時または正確に同時に、送信者２０１からネットワーク２０２を介して受信者２０３へ送信される（または、他の場所で論じられたように、メモリに入力される）。１つのパケット５２０は、ＩＰ識別ヘッダ５２２と、ＵＤＰヘッダ５２４と、フレームのシーケンスの現フレームＮの２つのフロントチャネル（ＦＬ及びＦＲ）に関するソースフレーム情報５２６、並びにシーケンスの前フレームＮ‐１、Ｎ‐２、Ｎ‐３、及びＮ‐４に対応するＦＥＣフレーム情報５２８に対応する符号化情報を含むペイロードとを包含する。ＵＤＰヘッダ５２４とペイロード（現フレームＮの符号化情報）との間に示される追加のヘッダ５２５は、フレーム番号、並びにソース符号化ビットレート及びＦＥＣ符号化ビットレートに関する情報を含み得る。ＦＥＣフレーム情報５２８は、６つの音声チャネル全てを再構築できるデータを含む。ＦＥＣフレーム５２８を符号化することは、ドルビープロロジック符号化を使用することを含み得、これにより、音声情報の６つのチャネルを、本明細書で左チャネル及び右チャネルと称される２つのチャネルに符号化することが可能となる。この特定の実施態様は、送信されるパケットの帯域幅及びメモリ要件を低減するという利点を有する。一般に、音声サンプルのプロロジック符号化の式は、以下のとおりである。
左チャネル＝ＦＬ＋ｓ＊（ＳＬ＋ＳＲ）＋ｃ＊Ｃ＋ｃ＊ＬＦＥ  及び
右チャネル＝ＦＲ−ｓ＊（ＳＬ＋ＳＲ）＋ｃ＊Ｃ＋ｃ＊ＬＦＥ  であり、
ｓ＝０．５〜１．０
ｃ＝０．７０７
ＦＬ／ＦＲ＝フロント左／右チャネル
ＳＬ／ＳＲ＝サラウンド左／右チャネル
Ｃ＝センターチャネル
Ｌ＝重低音効果チャネル  である。
【００５３】
前述の方法で符号化された情報は、例えば後述されるように、受信者側で復号化され、情報の６チャネル全てが抽出され得る。当業者は、５．１音声に関する他の既存の符号化及び復号化技術を、本明細書で開示される教示に適合させることができる。
【００５４】
第２のパケット５３０は、別個のＩＰ識別５３２と、ＵＤＰヘッダ５３４と、残りの４つのチャネル（ＳＬ、ＳＲ、Ｃ、及びＬＦＥ）の符号化ソースフレーム情報５３６を含むペイロードとを包含する。第２のパケット５３０に、ＦＥＣフレームは含まれない。さらに、残りの４つのチャネルに対し、ＦＥＣフレームが生成される必要はない。ソースフレームを別個のパケットに分割することにより、各パケットをより小さくすることが可能となり、パケット損失ではより頑強なフレーム誤り訂正が可能となる。フロントチャネルと３．１チャネルに分割することで、受信者システムは、フロントチャネルパケットが失われた場合、３．１チャネルからフロントチャネルを再構築することができ、または３．１チャネルパケットが失われた場合、フロントチャネルパケットのＦＥＣ部分から３．１チャネルを再構築することができる。
【００５５】
図５のパケット配置は、図４に示されたフローにおいて単一のデータパケット４２０の代わりに使用することができる。図２及び図４で示される方法は一般に、５．１音声に関して開示された本発明の特定の実施態様に準拠する。論述された特定の実施態様は、どのフレームが受信者に届いたかに応じて、異なる方法で誤り訂正を処理することができる。
【００５６】
ＦＬ及びＦＲチャネルのソースフレームを含むデータパケット５２０が受信者に届かなかった場合、受信側のコンピューティングシステムは、その後に受信したパケットのＦＥＣフレームから、これらのチャネルを再構築することができる。
【００５７】
受信者システムがステレオを受信したが、５．１音声機能を有する場合、受信者システムは、左及び右チャネルの信号のアップミキシング処理を行って、他の３．１チャネルを生成し得る。アップミキシング処理を行うための前述の式は、次のとおりである。
Ｃ＝ｃ＊（Ｌｔ＋Ｒｔ）
Ｌ＝ｃ＊（Ｌｔ＋Ｒｔ）及びローパスフィルターを適用
ＳＬ＝ｓ＊（ＬＴ−Ｒｔ）、時間遅延及び＋９０度の位相変位
ＳＲ＝ｓ＊（ＬＴ−Ｒｔ）、時間遅延及び−９０度の位相変位
ｓ＝０．５〜１．０
ｃ＝０．７０７
【００５８】
当業者は、モノラルサウンドと７．１サラウンドサウンドを含むがこれらに限定されない他の音声システム間で変換を行うために、前述の発明された式と同様の集合を適用することができる。
【００５９】
再構築はまた、ＦＥＣフレーム及び３．１チャネルソースフレームの両方を使用して、ＦＬ及びＦＲチャネルを回復させることを含み得る。ＦＥＣフレーム及び３．１チャネルソースフレームの両方を使用してフレームを再構築する場合、どちらか一方のみを使用した場合よりも高い解像度の出力フレームを得られる可能性があり得る。
【００６０】
限定ではなく例示として、５．１音声データは、以下のようにＦＥＣフレーム（Ｌｔ／Ｒｔ）及び３．１データ（ＳＬ／ＳＲ、Ｃ、Ｌ）の両方を用いて再構築され得る。
ＦＬ＝Ｌｔ−ｓ＊（ＳＬ＋ＳＲ）−ｃ＊Ｃ−ｃ＊Ｌ
ＦＲ＝Ｒｔ＋ｓ＊（ＳＬ＋ＳＲ）−ｃ＊Ｃ−ｃ＊Ｌ
ｓ＝０．５〜１．０
ｃ＝０．７０７
【００６１】
ＳＬ、ＳＲ、Ｃ、及びＬＦＥチャネルのソースフレームを含むデータパケット５３０が受信者に届かなかった場合、符号化３．１チャネルフレームデータを含む後続パケットのＦＥＣフレーム情報から、これらのチャネルを再構築することができる。この場合、以下の式を使用して、プロロジック符号化ＦＥＣファイルを復号化しなければならない。
Ｃ＝ｃ＊（Ｌｔ＋Ｒｔ）
Ｌ＝ｃ＊（Ｌｔ＋Ｒｔ）及びローパスフィルターを適用
ＳＬ＝ｓ＊（ＬＴ−Ｒｔ）、時間遅延及び＋９０度の位相変位
ＳＲ＝ｓ＊（ＬＴ−Ｒｔ）、時間遅延及び−９０度の位相変位
ｓ＝０．５〜１．０
ｃ＝０．７０７
【００６２】
当業者は、モノラルサウンドと７．１サラウンドサウンドを含むがこれらに限定されない他の音声システム間で変換を行うために、前述の発明された式と同様の集合を適用することができる。
【００６３】
データパケット５２０及び５３０の両方が受信者に届かなかった場合、その後に送信され受信されたＦＥＣフレームから、全てのチャネル情報は再構築され得る。関連する再構築の式（前と同じ略語を使用）は以下のとおりである。
ＦＬ＝Ｌｔ
ＦＲ＝Ｒｔ
Ｃ＝ｃ＊（Ｌｔ＋Ｒｔ）
Ｌ＝ｃ＊（Ｌｔ＋Ｒｔ）及びローパスフィルターを適用
ＳＬ＝ｓ＊（ＬＴ−Ｒｔ）、時間遅延及び＋９０度の位相変位
ＳＲ＝ｓ＊（ＬＴ−Ｒｔ）、時間遅延及び−９０度の位相変位
ｓ＝０．５〜１．０
ｃ＝０．７０７
【００６４】
当業者は、モノラルサウンドと７．１サラウンドサウンドを含むがこれらに限定されない他の音声システム間で変換を行うために、前述の発明された式と同様の集合を適用することができる。
【００６５】
データパケット５２０及び５３０の両方が到着した場合、必ずしも再構築の必要はなく、パケットからのデータを組み合わせて、出力フレームが形成され得る。
【００６６】
ステレオまたはその他の多チャネル音声システムを処理する実施態様は、送信者側の１つのシステムで音声を処理して、受信者側の別のシステムで音声を格納または出力することができるように適応させることも可能である。このような実施態様により、サラウンドサウンド符号化とステレオ符号化とを動的に切り替えることも可能となり得る。
【００６７】
１つの特定の実施態様は、以下のとおりである。送信者側のシステムにより生成されるソース音声が元々ステレオであるのに対し、受信者側で生成される出力が５．１サラウンドサウンドである場合、送信者側システムは、音声を２チャンネルのみのステレオとして扱い、図４で概説したような手順を使用し得る。受信者システムはそこで、ステレオを出力するという選択肢、または受信データを正しい音声システムに合わせるために、同じ式を用いてフレーム情報を５．１にアップミキシングするという選択肢を有する。送信者側のソース音声は５．１サラウンドサウンドであるのに対し、受信者システムはステレオしか処理できない場合、または帯域幅の制約もしくは出力システムの制限による動的な調整が原因で、送信者システムはステレオ送信に限定されている場合、通常のソースフレームをプロロジック符号化フレーム（全５．１チャネルの情報を保持）で上書きすることで、ステレオ音声ストリームは、プロロジック符号化ソースフレーム及びプロロジック符号化ＦＥＣフレームを保持することが可能となる。これにより、出力制限に応じて、受信者側においてステレオまたは５．１で再構築することが可能になる。パケット構造は、図５で示したものである。
【００６８】
説明された手順と併せて、送信者と受信者との間で、送信された音声がサラウンドサウンドであるか、ステレオであるかに関する通知を実施することができる。この通知は、制御チャネルを介して別個のデータパケットにより送信されてもよく、送信されるデータパケットのヘッダに含まれてもよく、または当業者が考案し得るその他の手段を通して送信されてもよい。
【００６９】
当業者は、送信者からの音声が、受信者側の出力とは異なるチャネルを有する他の事例に、開示された出願の教示を適用することができる。当業者は、ステレオ及びドルビー７．１サラウンドサウンドを非限定的に含み、かつ本明細書で開示された教示に準拠し対応する他の音声システムのデータパケット配置を構築することができる。
【００７０】
上記の構成要素は、ハードウェア、ソフトウェア、ファームウェア、またはこれらのある組み合せで実装され得る。
【００７１】
上記は、本開示の様々な例示的実施態様の完全な説明であるが、様々な代替物、変更物、及び均等物を使用することが可能である。従って、本発明の範囲は、上記の説明に限定されるものと解釈されるべきではなく、代わりに、添付の請求項とそれらの均等物の全範囲とを併せて参照して特定されるべきである。望ましいか否かに関わらず本明細書において説明される任意の特徴は、望ましいか否かに関わらず本明細書において説明される任意の他の特徴と組み合わせられ得る。下記の特許請求の範囲において、不定冠詞「ａ」または「ａｎ」は、特に明記される場合を除いて、冠詞の後に続く１つ以上の名詞の数量を指す。所定の請求項において「〜する手段（ｍｅａｎｓ  ｆｏｒ）」または「〜するステップ（ｓｔｅｐ  ｆｏｒ）」という句を用いて、手段またはステップ及び機能（ミーンズ・プラス・ファンクションまたはステップ・プラス・ファンクション）限定が明示的に列挙されない限り、添付の請求項の範囲は、手段またはステップ及び機能限定を含むと解釈されるべきではない。
【図１】
0006893237.tif 000002
【図２】
0006893237.tif 000003
【図３Ａ】
0006893237.tif 000004
【図３Ｂ】
0006893237.tif 000005
【図４】
0006893237.tif 000006
【図５】
0006893237.tif 000007