特表 2022-531998 ユーザ・データグラム・プロトコル（ＵＤＰ）を利用するロバストなビデオ送信のためのシステム、デバイス、及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-07-13

(54)【発明の名称】ユーザ・データグラム・プロトコル（ＵＤＰ）を利用するロバストなビデオ送信のためのシステム、デバイス、及び方法

(51)【国際特許分類】

   H04L 65/70 20220101AFI20220706BHJP

   H04L 65/75 20220101ALI20220706BHJP

【ＦＩ】

H04L65/70

H04L65/75

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2021502460

(86)(22)【出願日】2020-05-03

(85)【翻訳文提出日】2021-01-12

(86)【国際出願番号】 IL2020050490

(87)【国際公開番号】W WO2020230118

(87)【国際公開日】2020-11-19

(31)【優先権主張番号】62/846,669

(32)【優先日】2019-05-12

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/949,516

(32)【優先日】2019-12-18

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＢＬＵＥＴＯＯＴＨ

２．ＪＡＶＡ

３．ＪＡＶＡＳＣＲＩＰＴ

４．ＶＥＲＩＬＯＧ

５．ＶＩＳＵＡＬ ＢＡＳＩＣ

６．ＭＡＴＬＡＢ

７．ＰＹＴＨＯＮ

(71)【出願人】

【識別番号】521016427

【氏名又は名称】アミモン リミテッド

(74)【代理人】

【識別番号】110000855

【氏名又は名称】特許業務法人浅村特許事務所

(72)【発明者】

【氏名】レズニック、ツビ

(57)【要約】

ユーザ・データグラム・プロトコル（ＵＤＰ）オーバー・インターネット・プロトコル（ＩＰ）通信リンクを介してビデオを送信するためのシステム、デバイス、及び方法。方法は、ビデオ・エンコーダによってビデオの各フレームごとに圧縮データのＮ個のパケットのセットを生成することであって、Ｎが自然数である、生成することと、そのビデオの特定のフレームについてＮ個のパケットの各セットを生成すると、そのビデオの他のビデオ・フレームの符号化又はパケット化を待つことなしに、そのＵＤＰオーバーＩＰ通信リンクを介して、単一の符号化されたビデオ・フレームに対応するＮ個のパケットのセットの送信を直ちに実施することとを含む。そのビデオ・フレームの各パケットは、少なくとも、粗いビデオ・データ・パケット部分と、細かいビデオ・データ・パケット部分と、また随意に、サブフレーム・マッピング情報を含むヘッダ・パケット部分とを含む。

【特許請求の範囲】

【請求項1】

ユーザ・データグラム・プロトコル（ＵＤＰ）オーバー・インターネット・プロトコル（ＩＰ）通信リンクを介してビデオを送信する方法であって、前記方法は、
ビデオ・エンコーダによって前記ビデオの各フレームごとに圧縮データのＮ個のパケットのセットを生成することであって、Ｎが自然数である、生成することと、
前記ビデオの特定のフレームについてＮ個のパケットの各セットを生成すると、前記ビデオの他のビデオ・フレームの符号化又はパケット化を待つことなしに、前記ＵＤＰオーバーＩＰ通信リンクを介して、単一の符号化されたビデオ・フレームに対応するＮ個のパケットの前記セットの前記送信を直ちに実施することと
を含み、
前記ビデオ・フレームの各パケットが、少なくとも、
（ｉ）粗いビデオ・データ・パケット部分と、
（ｉｉ）細かいビデオ・データ・パケット部分と
を含む、方法。

【請求項2】

各パケットの前記粗いビデオ・データ・パケット部分について、バイト単位の固定サイズ（Ｓ２）を維持することであって、前記サイズ（Ｓ２）が、前記単一の特定のビデオ・フレームに対応するパケットの前記セットの全体にわたって固定される、維持することと、
各パケットの前記細かいビデオ・データ・パケット部分について、バイト単位の固定サイズ（Ｓ３）を維持することであって、前記サイズ（Ｓ３）が、前記単一の特定のビデオ・フレームに対応するパケットの前記セットの前記全体にわたって固定される、維持することと
を含む、請求項１に記載の方法。

【請求項3】

前記ビデオの異なるフレームについて、利用されるＳ２の値とＳ３の値とを動的に変えること
を含み、
Ｓ２の前記値が、前記ビデオの各フレームのすべてのパケットにわたって固定されたままであるが、前記ビデオの少なくとも１つの他のフレームにおいてＳ２の異なる値に変わり、
Ｓ３の前記値が、前記ビデオの各フレームのすべてのパケットにわたって固定されたままであるが、前記ビデオの少なくとも１つの他のフレームにおいてＳ３の異なる値に変わる、
請求項２に記載の方法。

【請求項4】

特定のフレームについての細かいビデオ・データという犠牲を払って、前記特定のフレームについての増加された量の粗いビデオ・データを収容するために、前記粗いビデオ・データ・パケット部分の前記サイズを動的に増加させ、それぞれ前記細かいビデオ・データ・パケット部分の前記サイズを動的に低減すること
を含む、請求項１から３までのいずれか一項に記載の方法。

【請求項5】

ビデオ・フレームごとに送信されるパケットのセットにおいて、
粗いビデオ・データを搬送するための粗いビデオ・データ・パケット部分の第１の数（Ｃ１）を指定することと、
前記粗いビデオ・データを搬送する代わりに、前記粗いビデオ・データの前方誤り訂正（ＦＥＣ）コードについての冗長データを搬送するための粗いビデオ・データ・パケット部分の第２の数（Ｃ２）を指定することと
を含む、請求項１から４までのいずれか一項に記載の方法。

【請求項6】

ビデオ・フレームごとに送信されるパケットのセットにおいて、
細かいビデオ・データを搬送するための細かいビデオ・データ・パケット部分の第１の数（Ｆ１）を指定することと、
前記細かいビデオ・データを搬送する代わりに、前記細かいビデオ・データの前方誤り訂正（ＦＥＣ）コードについての冗長データを搬送するための細かいビデオ・データ・パケット部分の第２の数（Ｆ２）を指定することと
を含む、請求項１から５までのいずれか一項に記載の方法。

【請求項7】

Ｃ１の値と、Ｃ２の値と、Ｆ１の値と、Ｆ２の値とを選択すること
を含み、
Ｎが、特定のビデオ・フレームについて送信されるパケットの総数であり、
Ｃ１＋Ｃ２＝Ｎであり、
Ｆ１＋Ｆ２＝Ｎであり、
Ｆ１＞Ｃ１である、
請求項１から６までのいずれか一項に記載の方法。

【請求項8】

Ｎの値と、Ｃ１の値と、Ｃ２の値と、Ｆ１の値と、Ｆ２の値とを選択すること
を含み、
Ｎが９であり、
Ｃ１が５であり、Ｃ２が４であり、
Ｆ１が８であり、Ｆ２が１である、
請求項１から７までのいずれか一項に記載の方法。

【請求項9】

前記ビデオ・フレームの各パケットが、
（ｉ）ヘッダ・パケット部分と、
（ｉｉ）粗いビデオ・データ・パケット部分と、
（ｉｉｉ）細かいビデオ・データ・パケット部分と
を含み、
前記方法は、
単一の特定のビデオ・フレームに対応するパケットのセット中の各パケットの前記ヘッダ・パケット部分について、バイト単位の固定サイズ（Ｓ１）を維持することであって、前記サイズ（Ｓ１）が、パケットの前記セットの全体にわたって固定される、維持することと、
各パケットの前記粗いビデオ・データ・パケット部分について、バイト単位の固定サイズ（Ｓ２）を維持することであって、前記サイズ（Ｓ２）が、前記単一の特定のビデオ・フレームに対応するパケットの前記セットの前記全体にわたって固定される、維持することと、
各パケットの前記細かいビデオ・データ・パケット部分について、バイト単位の固定サイズ（Ｓ３）を維持することであって、前記サイズ（Ｓ３）が、前記単一の特定のビデオ・フレームに対応するパケットの前記セットの前記全体にわたって固定される、維持することと
を含む、請求項１に記載の方法。

【請求項10】

前記ビデオ・フレームの各パケットが、
（ｉ）ヘッダ・パケット部分と、
（ｉｉ）粗いビデオ・データ・パケット部分と、
（ｉｉｉ）細かいビデオ・データ・パケット部分と
を含み、
前記方法は、
前記ビデオの異なるフレームについて、利用されるＳ１の値と、Ｓ２の値と、Ｓ３の値とを動的に変えることを含み、
Ｓ１の前記値が、前記ビデオの各フレームのすべてのパケットにわたって固定されたままであるが、前記ビデオの少なくとも１つの他のフレームにおいてＳ１の異なる値に変わり、
Ｓ２の前記値が、前記ビデオの各フレームのすべてのパケットにわたって固定されたままであるが、前記ビデオの少なくとも１つの他のフレームにおいてＳ２の異なる値に変わり、
Ｓ３の前記値が、前記ビデオの各フレームのすべてのパケットにわたって固定されたままであるが、前記ビデオの少なくとも１つの他のフレームにおいてＳ３の異なる値に変わる、
請求項９に記載の方法。

【請求項11】

ビデオ・フレームのＮ個のパケットの前記セットにおいて、
ビデオ・ヘッダ・データを搬送するためのビデオ・ヘッダ・データ・パケット部分の第１の数（Ｈ１）を指定することと、
前記ビデオ・ヘッダ・データを搬送する代わりに、前記ビデオ・ヘッダ・データの前方誤り訂正（ＦＥＣ）コードについての冗長データを搬送するためのビデオ・ヘッダ・データ・パケット部分の第２の数（Ｈ２）を指定することと
を含む、請求項１から１０までのいずれか一項に記載の方法。

【請求項12】

Ｎの値と、Ｈ１の値と、Ｈ２の値と、Ｃ１の値と、Ｃ２の値と、Ｆ１の値と、Ｆ２の値とを選択すること
を含み、
Ｃ１＜Ｆ１であり、
Ｈ１がＣ１よりも小さいか又はそれに等しい、
請求項１から１１までのいずれか一項に記載の方法。

【請求項13】

Ｎの値と、Ｈ１の値と、Ｈ２の値と、Ｃ１の値と、Ｃ２の値と、Ｆ１の値と、Ｆ２の値とを選択すること
を含み、
Ｎが９であり、
Ｈ１が３であり、Ｈ２が４であり、
Ｃ１が５であり、Ｃ２が４であり、
Ｆ１が８であり、Ｆ２が１である、
請求項１から１２までのいずれか一項に記載の方法。

【請求項14】

特定のフレームの細かいビデオ・データを搬送するために指定された細かいビデオ・データ・パケット部分の数が、前記特定のフレームについてのすべての前記細かいビデオ・データを搬送するには十分でない場合、細かいビデオ・データの前方誤り訂正（ＦＥＣ）コードの冗長バイトを記憶するために前に指定された少なくとも１つの細かいビデオ・データ・パケット部分に、前記特定のフレームの細かいビデオ・データを記憶すること
を含む、請求項１から１３までのいずれか一項に記載の方法。

【請求項15】

特定のフレームの細かいビデオ・データを搬送するために指定された細かいビデオ・データ・パケット部分の前記数が、前記特定のフレームについてのすべての前記細かいビデオ・データを搬送するには十分でない場合、Ｆ１の前記値を動的に増加させ、それぞれＦ２の前記値を動的に減少させること
を含む、請求項１から１４までのいずれか一項に記載の方法。

【請求項16】

前記ビデオ送信を受信するように動作する受信デバイスにおいて、特定のビデオ・フレームについて受信された受信されたビデオ・ヘッダ部分中の情報に基づいて、前記特定のビデオ・フレームのパケットの前記セットについてＦ１の新しい値とＦ２の新しい値とを決定すること
を含む、請求項１から１５までのいずれか一項に記載の方法。

【請求項17】

特定のフレームの粗いビデオ・データを搬送するために指定された粗いビデオ・データ・パケット部分の数が、前記特定のフレームについてのすべての前記粗いビデオ・データを搬送するには十分でない場合、前記特定のフレームの細かいビデオ・データを記憶するために前に指定された少なくとも１つのパケット部分に、前記特定のフレームの粗いビデオ・データを記憶すること
を含む、請求項１から１６までのいずれか一項に記載の方法。

【請求項18】

前記ビデオ送信を受信するように動作する受信デバイスにおいて、特定のビデオ・フレームについて受信された受信されたビデオ・ヘッダ部分中の情報に基づいて、前記特定のビデオ・フレームのパケットの前記セットについてＣ１の新しい値とＣ２の新しい値とを決定すること
を含む、請求項１から１７までのいずれか一項に記載の方法。

【請求項19】

前記ビデオの各フレームについて生成されたパケットの各セットが、
（ｉ）粗いビデオ・データを搬送するために指定されたパケット部分
対
（ｉｉ）粗いビデオ・データの前方誤り訂正（ＦＥＣ）コードを搬送するために指定されたパケット部分
の固定比（Ｒ１）を利用し、
また、
（Ａ）細かいビデオ・データを搬送するために指定されたパケット部分
対
（Ｂ）細かいビデオ・データの前方誤り訂正（ＦＥＣ）コードを搬送するために指定されたパケット部分
の固定比（Ｒ２）を利用し、
また、
（ａ）ビデオ・ヘッダ・データを搬送するために指定されたパケット部分
対
（ｂ）ビデオ・ヘッド・データの前方誤り訂正（ＦＥＣ）コードを搬送するために指定されたパケット部分
の固定比（Ｒ３）を利用する、
請求項１から１８までのいずれか一項に記載の方法。

【請求項20】

前記ビデオの各フレームについて生成されたＮ個のパケットの各セットが、少なくとも、（ｉ）ビデオ・ヘッダ情報を記憶する第１の数（Ｈ１）のビデオ・ヘッダ・パケット部分と、（ｉｉ）前記ビデオ・ヘッダ・ビデオ情報の前方誤り訂正（ＦＥＣ）冗長を記憶する第２の数（Ｈ２）のビデオ・ヘッダ・パケット部分とを含み、
また、あらかじめ定義されたサイズ制約が許容する場合、（Ｉ）粗いビデオ・データを記憶する第１の数（Ｃ１）の粗いビデオ・データ・パケット部分と、（ＩＩ）前記粗いビデオ・データについての前方誤り訂正（ＦＥＣ）冗長を記憶する第２の数（Ｃ２）のパケット部分とをさらに含み、
また、あらかじめ定義されたサイズ制約が許容する場合、（ＩＩＩ）細かいビデオ・データを記憶する第１の数（Ｆ１）の細かいビデオ・データ・パケット部分と、（ＩＶ）前記細かいビデオ・データについての前方誤り訂正（ＦＥＣ）冗長を記憶する第２の数（Ｆ２）のパケット部分とをさらに含む、
請求項１から１９までのいずれか一項に記載の方法。

【請求項21】

ビデオ・フレームごとのＮ個のパケットの前記セットについてのあらかじめ定義されたバイトサイズ制約に基づいて、
特定のビデオ・フレームについて、Ｎ個のパケットの前記セットから、特定のビデオ・フレームの前記細かいビデオ・データについての前方誤り訂正（ＦＥＣ）コードについての前記冗長データの少なくとも一部を除外することを動的に決定すること
を含む、請求項１から２０までのいずれか一項に記載の方法。

【請求項22】

ビデオ・フレームごとのＮ個のパケットの前記セットについてのあらかじめ定義されたバイトサイズ制約に基づいて、
特定のビデオ・フレームについて、Ｎ個のパケットの前記セットから、（ｉ）特定のビデオ・フレームの前記細かいビデオ・データについての前方誤り訂正（ＦＥＣ）コードについての前記冗長データの少なくとも一部と、（ｉｉ）前記特定のビデオ・フレームについての前記細かいビデオ・データの少なくとも一部とを除外することを動的に決定すること
を含む、請求項１から２１までのいずれか一項に記載の方法。

【請求項23】

ビデオ・フレームごとのＮ個のパケットの前記セットについてのあらかじめ定義されたバイトサイズ制約に基づいて、
特定のビデオ・フレームについて、Ｎ個のパケットの前記セットから、（ｉ）特定のビデオ・フレームの前記細かいビデオ・データについての前方誤り訂正（ＦＥＣ）コードについての前記冗長データの全体と、（ｉｉ）前記特定のビデオ・フレームについての前記細かいビデオ・データの全体とを除外することを動的に決定すること
を含む、請求項１から２２までのいずれか一項に記載の方法。

【請求項24】

前記ビデオ送信を受信するように動作する受信デバイスにおいて、細かいビデオ・データが送信デバイスによる送信から除外された、前記特定のビデオ・フレームの１つ又は複数のサブフレームを復号すること
を含む、請求項１から２３までのいずれか一項に記載の方法。

【請求項25】

前記ビデオ送信を受信するように動作する受信デバイスにおいて、
特定のビデオ・フレームについて、完全な細かいビデオ・データでなく、部分的な細かいビデオ・データのみを受信することと、
前記受信デバイスのＦＥＣデコーダが、前記特定のビデオ・フレームについての前記完全な細かいビデオ・データを再構築するのに十分な情報を有する場合、前記特定のビデオ・フレームについての前記完全な細かいビデオ・データを再構築することと、
前記受信デバイスの前記ＦＥＣデコーダが、前記特定のビデオ・フレームについての前記完全な細かいビデオ・データを再構築するのに十分な情報を有しない場合、前記特定のビデオ・フレームの少なくとも１つ又は複数の細かいサブフレームを再構築することと
を含む、請求項１から２４までのいずれか一項に記載の方法。

【請求項26】

前記ビデオの各フレームの送信を制約する、フレームごとにＮｍａｘ個のパケットの上界値を設定すること
を含み、
Ｎｍａｘが、前記ビデオのすべてのフレームについて一様である自然数であり、
前記ビデオの各フレームの圧縮ビデオ・データが、フレームごとに最高Ｎｍａｘ個のパケットを使用することによって送信される、
請求項１から２５までのいずれか一項に記載の方法。

【請求項27】

ビデオ・エンコーダにおいて、前記ビデオの特定のフレームについての圧縮ビデオのＫ個のパケットを生成することであって、Ｋが、前記ビデオのすべてのフレームにわたって必ずしも固定されるとは限らない自然数である、生成することと、
ＫがＮｍａｘよりも小さいか又はそれに等しい場合、前記フレームについてのすべてのＫ個のパケットを送信することと、
ＫがＮｍａｘよりも大きい場合、前記フレームについての前記Ｋ個のパケットのうちの最初のＮｍａｘ個のパケットのみを送信し、前記フレームについての、前記最初のＮｍａｘ個のパケットを越えるパケットの送信を回避することと
を含む、請求項２６に記載の方法。

【請求項28】

ビデオ・フレームごとのＮ個のパケットの前記セットの各パケットが、送信されたサブフレームの前記粗いビデオ・データと前記細かいビデオ・データとのマップとして利用されるビデオ・ヘッダ部分を含み、
前記ビデオ・ヘッダは、前記ビデオ・フレームについての前記前方誤り訂正（ＦＥＣ）コードの一部又はすべてが、前記ＦＥＣコードのあまりにも少ないバイトが受信デバイスに到着したので適切に復号されなかった場合でも、前記ビデオ・フレームの１つ又は複数のサブフレームを復号するために、前記受信デバイスが、到着した前記細かいビデオ・データ及び／又は到着した前記粗いビデオ・データを少なくとも部分的に利用することを可能にする、
請求項１から２７までのいずれか一項に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本特許出願は、その全体が参照により本明細書に組み込まれる、２０１９年１２月１８日に出願された米国特許出願第６２／９４９，５１６号、及び、その全体が参照により本明細書に組み込まれる、２０１９年５月１２日に出願された米国特許出願第６２／８４６，６６９号の利益及び優先権を主張する。

【0002】

本発明は、通信システムの分野に関する。

【背景技術】

【0003】

電子デバイス及びコンピューティング・デバイスは、世界中の何百万人ものユーザによって毎日利用されている。たとえば、ラップトップ・コンピュータ、デスクトップ・コンピュータ、スマートフォン、タブレット、及び他の電子デバイスが、インターネットをブラウズすること、デジタル・コンテンツを消費すること、オーディオ及びビデオをストリーミングすること、電子メール（ｅメール）メッセージを送り、受信すること、インスタント・メッセージング（ＩＭ：Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ）、ビデオ会議、ゲームをプレイすることなどのために利用されている。

【0004】

多くの電子デバイスは、たとえば、Ｗｉ－Ｆｉを使用して、セルラー通信を使用して、インターネット上でなど、１つ又は複数のワイヤレス通信リンク又はネットワークを介して、互いに、或いはリモート・サーバ又はリモート・エンティティと通信する。いくつかの電子デバイスは、ビデオ・データを搬送するワイヤレス通信信号を受信するために利用されて、そのような電子デバイスは、そのディスプレイ・ユニット上でストリーミング・ビデオ又はビデオ・クリップを再生することが可能になる。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】米国特許出願公開第２０１６／００７３１２２号明細書

【発明の概要】

【課題を解決するための手段】

【0006】

本発明のいくつかの実施例は、ユーザ・データグラム・プロトコル（ＵＤＰ：Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を利用するロバストなビデオ送信のためのシステム、デバイス、及び方法を提供し得る。たとえば、方法は、ビデオ・エンコーダによってビデオの各フレームごとに圧縮データのＮ個のパケットのセットを生成することであって、Ｎが自然数である、生成することと、そのビデオの特定のフレームについてＮ個のパケットの各セットを生成すると、そのビデオの他のビデオ・フレームの符号化又はパケット化を待つことなしに、そのＵＤＰオーバーＩＰ通信リンクを介して、単一の符号化されたビデオ・フレームに対応するＮ個のパケットのセットの送信を直ちに実施することとを含む。そのビデオ・フレームの各パケットは、少なくとも、粗い（Ｃｏａｒｓｅ）ビデオ・データ・パケット部分と、細かい（Ｆｉｎｅ）ビデオ・データ・パケット部分と、また随意に、サブフレーム・マッピング情報を含むヘッダ・パケット部分とを含む。

【0007】

本発明は、他の及び／又は追加の利点及び／又は利益を提供し得る。

【図面の簡単な説明】

【0008】

【図1】本発明のいくつかの例示的な実施例による、ＵＤＰオーバーＩＰ接続を介する送信の対象であるＨ．２６５ビデオのパケットのセットの概略図である。

【図2】本発明のいくつかの例示的な実施例による、フレーム・グループ化を例示する概略図である。

【図3】本発明のいくつかの例示的な実施例による、システムの概略図である。

【図4】本発明のいくつかの例示的な実施例による、サブフレームに分割されたビデオ・フレームの概略図である。

【図5】本発明のいくつかの例示的な実施例による、ＵＤＰパケットを使用するビデオ送信におけるビット・レート及び誤り伝搬を最小限に抑える方法のフロー・チャートである。

【図6】本発明のいくつかの例示的な実施例による、ＵＤＰパケットを使用するビデオ送信における小さいオーバーヘッド隠蔽（ｃｏｎｃｅａｌｍｅｎｔ）を実施する方法のフローチャートである。

【図7】本発明のいくつかの例示的な実施例による、ＵＤＰパケットを使用するビデオ送信における小さいオーバーヘッド隠蔽を実施する方法のフローチャートである。

【図8】本発明のいくつかの例示的な実施例による、ＵＤＰパケットを使用するビデオ送信における小さいオーバーヘッド隠蔽を実施する方法のフローチャートである。

【図9】本発明のいくつかの例示的な実施例による、ＵＤＰパケットを使用するビデオ送信における小さいオーバーヘッド隠蔽を実施する方法のフローチャートである。

【発明を実施するための形態】

【0009】

本発明のいくつかの実施例は、ビデオ、特に、高効率ビデオ・コーディング（ＨＥＶＣ：Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）又はＨ．２６５又はＭＰＥＧ－Ｈ Ｐａｒｔ２ビデオ圧縮規格、或いはＨ．２６４又はＭＰＥＧ－４ Ｐａｒｔ１０又はアドバンスト・ビデオ・コーディング（ＡＶＣ：Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ又はＭＰＥＧ－４ ＡＶＣ）ビデオ圧縮規格など、アドバンスト圧縮規格で圧縮又は符号化されたビデオの送信及び受信、並びに、本明細書で説明されるように、粗いデータ部分と細かい（又は精細（Ｒｅｆｉｎｅｍｅｎｔ））データ部分とを使用して表される圧縮ビデオに関する送信及び受信を可能にし得る。本発明のいくつかの実施例は、Ｈ．２６４ ＳＶＣを使用して、又はＨ．２６４／ＭＰＥＧ－４ ＡＶＣビデオ圧縮規格のアネックスＧ拡張を使用してなど、スケーラブル・ビデオ・コーディング（ＳＶＣ：Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）技法に従って、或いは、高品質ビデオ・ストリームが、２つ又はそれ以上のサブセット・ビットストリームに符号化され、サブセット・ビットストリームが、より低い空間解像度（より小さいスクリーン）を有するバージョン、及び／又はより低い時間解像度（より低いフレーム・レート）を有するバージョン、及び／又はより低い品質若しくは忠実度若しくは信号対雑音比（ＳＮＲ：Ｓｉｇｎａｌ－ｔｏ－Ｎｏｉｓｅ Ｒａｔｉｏ）を有するバージョンを表し得る、同様の技法によって、圧縮又は符号化されたビデオとともに利用され得る。

【0010】

「細かい」若しくは「細かいデータ」若しくは「細かいビデオ・データ」又は「精細」若しくは「精細データ」若しくは「精細ビデオ・データ」という用語、或いは同様の用語が本明細書で互換的に使用され、したがって、「細かい」は「精細」をも含み、又は意味し得、「精細」は「細かい」をも含み、又は意味し得る。いくつかの実施例では、「細かい」又は「精細」ビデオ・データは、フレームのより高い品質のバージョンを作成するために、粗いビデオ・データを有し、次いで、それの上に詳細を追加するか又はそれの上に組み込むことによって、ビデオ・デコーダがフレームの粗いバージョンに詳細を追加することを可能にする、データを含み得る。他の実施例では、「細かい」又は「精細」ビデオ・データは、必ずしもビデオ・フレームの粗いビデオ・データを利用又はそれに依拠することなしに、ビデオ・デコーダがそのフレームの高詳細バージョンを「ゼロから」再構築することを可能にする、データを含み得る。

【0011】

本出願人は、インターネット・プロトコル（ＩＰ：Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）接続上で、すなわち、送信制御プロトコル（ＴＣＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を介して、又はユーザ・データグラム・プロトコル（ＵＤＰ）を介して圧縮ビデオを送るための２つの主要なオプションがあることを了解している。本出願人は、圧縮ビデオのＴＣＰ送信において、その送信は、より信頼できるが、より高いレイテンシという欠点があり、圧縮ビデオのＵＤＰ送信において、その送信は、あまり信頼できないが、レイテンシ又は遅延がより低いことをさらに了解している。たとえば、本出願人は、ＵＤＰパケットが、通常、それの予定受信側に到着するか、又は（たとえば、不正な形式のパケットとして到着するのではなく）まったく到着しないかのいずれかであり、受信側サイド又はそれのビデオ・デコーダが、受信されるべきであったＵＤＰパケットが受信されなかったと決定するように構成され得ることを、了解した。本発明の実施例は、ＵＤＰ上でのビデオ送信の信頼性及び／又はロバストネスを増加させるように動作し得る。

【0012】

例示のために、本明細書の説明のいくつかの部分は、Ｈ．２６５ビデオに関し得るが、これは非限定的な例にすぎず、本発明の実施例は、他のタイプの圧縮ビデオ及び／又は符号化ビデオとともに使用され得る。本発明の実施例は、２つ又はそれ以上の部分、すなわち、粗い部分と細かい（又は精細）部分とを有することを特徴とするビデオ・データのハンドリング、送信、及び受信に好適であり得る。たとえば、粗い部分は、各ビデオ・フレームの低レベル表現を含み得、したがって、粗い部分の正常な受信及び復号は、受信エンティティが、少なくとも、フレームの粗い表現、又はフレームの低解像度バージョン、又は部分的に詳細なバージョンを作り出す又は表示することを可能にすることになり、これらは、高解像度の詳細を欠き得るが、依然として、閲覧者が、示されたコンテンツを理解することを可能にする、十分な量の視覚情報をその閲覧者に伝達するには十分であり得る。細かい部分又は精細部分は、受信エンティティが、フレームの高解像度バージョン又はフル解像度バージョン或いはフレームの十分に詳細なバージョンを作り出す及び表示することを可能にするデータを含み得、いくつかの実施例では、精細部分は、たとえば、（データの粗い部分においてすでに表されている）フレームの粗いバージョンと、それの詳細の全体をもつ、又は、粗いデータ部分において表されていない少なくともいくつかの追加の詳細をもつ、実際の元のフレームとの間の差に対応するデータを含み得る。いくつかの実施例では、たとえば、ビデオは、その全体が参照により本明細書に組み込まれる特許文献１で説明されるように、粗い部分と精細部分とを含み得る。

【0013】

いくつかの実施例は、個別フレームを有するビデオとともに動作し得、したがって、各フレームは、Ｍ個のサブフレームとして表され（又はＭ個のサブフレームに論理的に分割され）、Ｍは、２４個のフレームなど、１よりも大きい整数である。幅１９２０ピクセル×高さ１０８０ピクセルの総サイズ（又は寸法）を有するビデオ・フレーム４００の概略図である図４が参照される。フレーム４００は、１から２４までの番号を付けられた２４個のサブフレームに分割され、６行×４列の行列又はアレイとして配列され得、各そのようなサブフレームは、フレーム４００のエリア全体の１／２４に対応し、各そのようなサブフレームは、幅３２０ピクセル×高さ２７０ピクセルである。いくつかの実施例では、そのフレーム４００についてのデータ表現は、２４個のデータ部分を含み、各データ部分は、それらの連続する並び順にサブフレームに対応し得、したがって、各データ部分は、そのサブフレームについての粗いビデオ・データと、その後に続く、そのサブフレームについての精細ビデオ・データとを含み得る。他の実施例では、各サブフレームについての粗いデータは、サブフレームごとに次々にアグリゲートされ、次いで、すべてのサブフレームについての粗いデータの後に、それらのサブフレームについての精細データが続き、次々に続く。他のデータ構造が使用され得、ヘッダ部分が、使用されるデータ構造の特定のタイプ、並びにフレーム４００の各サブフレームの各そのような粗いデータ部分又は精細データ部分のデータの長さ（ビット数又はバイト数）を記述するデータ又はメタデータを含み得る。

【0014】

例示のために、本明細書の説明のいくつかの部分は、リード－ソロモン誤り訂正の利用に関し得るが、これは非限定的な例にすぎず、本発明によれば、誤り訂正又は前方誤り訂正（ＦＥＣ：Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）の他のタイプ又は方法が使用され得る。

【0015】

本発明のいくつかの例示的な実施例による、ＵＤＰ／ＩＰ上での送信の対象であるＨ．２６５ビデオのパケットのセット１００の概略図である図１が参照される。いくつかの実施例では、随意に、パケットのセット１００は、ＵＤＰ／ＩＰ上での送信の対象である単一のデータグラムに対応し得る。例示的な実装形態では、セット１００は、Ｈ．２６５符号化ビデオを搬送する９つのパケット１０１～１０９を含む。不均一誤り保護方式が適用され、したがって、符号化エンティティ又は送信エンティティは、同じパケット内で、粗いビデオ・データ及び／又は精細ビデオ・データ、並びに／或いは、粗いビデオ・データについてのリード－ソロモン誤り訂正コード及び／又は精細ビデオ・データについてのリード－ソロモン誤り訂正コードの、好適な組合せを記憶及び送信する。

【0016】

各パケット（１０１～１０９）は、複数のパケット部分、すなわち、パケットの通し番号（たとえば、あらかじめ定義された上限においてラップ・アラウンドする連続番号）を指示する初期パケット部分である（参照符号Ｚ１の下の図中に位置する）第１のパケット部分と、次いで、ビデオ・フレームのサブフレームに関するメタデータを指示するヘッダ・ビデオ情報を記憶する（参照符号Ｚ２の下の図中に位置する）ヘッダ・ビデオ・パケット部分と、次いで、受信側デバイスが、送信されたフレームの粗いバージョンを復号及び表示することを可能にするための、粗いビデオ・データを搬送する（参照符号Ｚ３の下の図中に位置する）粗いデータ・パケット部分と、次いで、受信側デバイスが、送信されたフレームの精細化されたバージョンを復号及び表示することを可能にする、データを搬送する（参照符号Ｚ４の下の図中に位置する）精細データ・パケット部分とを含み得る。

【0017】

特定の方式によれば、リード－ソロモン（ＲＳ：Ｒｅｅｄ－Ｓｏｌｏｍｏｎ）前方誤り訂正（ＦＥＣ）が使用される。（参照符号Ｚ５、Ｚ６及びＺ７の下の図中に位置する）細長い垂直「ＲＳ」矩形によって指示されるように、ＲＳワード（たとえば、各ＲＳワードは、元のデータを搬送する組織部と、パリティ／冗長部とを含む）は、同じタイプの複数の対応するパケット部分にわたって符号化される。本発明によれば、精細ビデオ・データに対する粗いビデオ・データに関して、またヘッダ・データに対する粗いビデオ・データに関して、異なるコード・レート（又はコーディング・レート、又はコード比）又は異なる情報レート（又は情報比）が使用される。コード・レートは、たとえば、有用又は非冗長であるデータ・ストリームの比率として定義され得、たとえば、ｋ／ｎのコード・レートは、ｋビットの有用な情報ごとに、システムが、より大きい数（ｎ）のビットのデータを生成し、したがって、ｎ＞ｋであり、したがって、（ｎ－ｋ）ビットが（たとえば、誤り訂正目的のための利用される）冗長データであることを指示する。

【0018】

たとえば、単一のビデオ・フレームに対応する９つのパケット１０１～１０９の特定のセットについて、第１のコーディング・レート（Ｒ１）が定義され、これは、（ｉ）粗いビデオ・データのリード－ソロモン・ワード中の元の（又は有用な、又は非冗長な、又は視覚コンテンツの実際の表現に直接対応する）粗いビデオ・バイトの数と（ｉｉ）粗いビデオ・データの前記リード－ソロモン・ワード中のバイトの総数との比である。同じ単一のビデオ・フレームに対応する９つのパケット１０１～１０９の同じセットについて、第２の異なるコーディング・レート（Ｒ２）が定義され、これは、（Ｉ）精細ビデオ・データのリード－ソロモン・ワード中の元の精細ビデオ・バイト・データの数と（ＩＩ）精細ビデオ・データの前記リード－ソロモン・ワード中のバイトの総数との比である。いくつかの実施例では、粗いビデオ・データ及び精細ビデオ・データのリード－ソロモン・ワードについての異なるコーディング・レートの利用の代わりに、又はそれに加えて、異なるタイプの前方誤り訂正（ＦＥＣ）アルゴリズムが使用され得る。

【0019】

たとえば、ビデオ・フレームごとのパケットの数がＮ＝９であるとき、好適な値は、（粗いビデオ・データのＲＳワードについての）第１のコーディング・レート＝Ｒ１＝５／９であり、同じビデオ・フレームについて、（精細ビデオ・データのＲＳワードについての）第２のコーディング・レート＝Ｒ２＝８／９であり得る。たとえば、単一のビデオ・フレームを表すＮ個のパケットの同じセットについて、Ｒ１はＲ２とは異なる。たとえば、単一のビデオ・フレームを表すＮ個のパケットの同じセットについて、Ｒ２はＲ１よりも大きい。たとえば、単一のビデオ・フレームを表すＮ個のパケットの同じセットについて、精細ビデオ・データのＲＳワードについての第２のコーディング・レート（Ｒ２）は、少なくとも３／４であり、粗いビデオ・データのＲＳワードについての第１のコーディング・レート（Ｒ１）はせいぜい２／３である。たとえば、第１のコーディング・レートＲ１は、１／１０から２／３までの範囲内にあるか、又は１／４から２／３までの範囲内にあり、第２のコーディング・レートＲ２は、３／４から１までの範囲内にあるか、又は０．６から０．９までの範囲内にある。他の好適な異なる値又は値の範囲が使用され得る。

【0020】

例示的な実施例では、パケットのセット１００は、（たとえば、１，３６０バイト又は１，４００バイトの一様なパケット長など、バイト単位の）一様なパケット長を有する９つのパケット１０１～１０９を含む。粗いビデオ・データは、セット１００の最初の５つのパケット１０１～１０５の粗いパケット部分にのみ記憶され、次の４つのパケット１０６～１０９の粗いパケット部分は、粗いビデオ・データを記憶しないが、代わりに、それらはリード－ソロモン・パリティ（又は冗長）を記憶し、これは、パケット１０１～１０５のうちの１つ又は複数、或いはいくつかが受信側に到着しなかった場合、パケット１０６～１０９中に含まれており、受信側に到着した、追加のＲＳパリティ（又はそれの少なくとも一部）を利用することによって、パケット１０１～１０９のうちの受信側に到着したパケットにリード－ソロモン誤り訂正を適用することによって、受信側が、それらのパケット１０１～１０５の粗いビデオ・データを再構築することを可能にする。同様に、精細ビデオ・データは、セット１００の最初の８つのパケット１０１～１０８の精細パケット部分にのみ記憶され、次のパケット１０９の精細パケット部分は、精細ビデオ・データを記憶しないが、代わりに、それはリード－ソロモン・パリティを記憶し、これは、パケット１０１～１０８のうちの１つ又は複数、或いはいくつかが受信側に到着しなかった場合、パケット１０１～１０８のうちの受信側に到着したパケットにリード－ソロモン誤り訂正を適用することによって、及び、パケット１０９中に含まれており、受信側に到着した、追加のＲＳパリティ（又はそれの少なくとも一部）を利用することによって、受信側が、それらのパケット１０１～１０９の精細ビデオ・データを再構築することを可能にする。

【0021】

粗いビデオ・データについてのリード－ソロモン・ワードのコーディング・レート（Ｒ１＝４／９など、Ｒ１）は、精細ビデオ・データについてのリード－ソロモン・ワードのコーディング・レート（Ｒ２＝８／９など、Ｒ２）とは異なることを諒解されたい。本出願人は、同じフレームのパケットの同じセットにわたる、精細データ部分に対する粗いデータ部分に関する、異なる又は不均一なコーディング・レート、或いは一様でないコーディング・レートのこの独自の方式が、パケットのうちの１つ又は複数が移動中に失われた場合であっても、受信側デバイスの、送信されたビデオを正しく復号する能力を改善し得ることを、了解している。本出願人は、粗いビデオ・データに関して、粗いビデオ・データ及びそれのＲＳワードが、受信側デバイスが、送信されたビデオ・フレームの少なくとも粗いバージョンを復号及び表示することを可能にするために最も重要であるので、２／３よりも小さいかそれに等しい、又は０．６７よりも小さい、又は０．６０よりも小さい、又は０．５０よりも小さい、又は０．４０よりも小さい、又は１／３から２／３までの範囲内にある、又は１／４から２／３までの範囲内にある、又は１／５から２／３までの範囲内にある、コーディング・レート（Ｒ１）を有することがより重要であることを、了解している。対照的に、本出願人は、精細ビデオ・データ及びそれのＲＳワードに関して、精細ビデオ・データが、送信されたビデオ・フレームを受信側デバイスが復号及び表示することを可能にするために二次的に重要であるにすぎず、それは、受信側デバイスが、すでに受信された粗いデータの品質又は詳細を精細化又は改善するのを可能にするように動作するにすぎないので、比較的低いコーディング・レートを有することがあまり重要でないことを了解した。したがって、第２のコーディング・レート（Ｒ２）は、たとえば、少なくとも３／４、又は少なくとも４／５、又は少なくとも５／６、又は少なくとも６／７、又は少なくとも７／８、又は他の好適な値であり得る。

【0022】

いくつかの実施例によれば、Ｒ１の単一の値とＲ２の単一の（異なる、より大きい）値とが、特定のビデオ送信のパケットのすべてのセットにわたって、すなわち、同じビデオ送信に対応する、又は受信側デバイスへの配信の対象である同じビデオ項目の送信に対応する、ＵＤＰ／ＩＰパケットのすべての様々なセットにわたって、一様に利用される。言い換えれば、本発明の実施例は、パケットの各セットが異なるサイズを有するようなパケットのセット（たとえば、特定のビデオ項目の配信について、ＮがＭとは異なるような、Ｎ個のパケットの第１のセット、及びその後に続く、Ｍ個のパケットの第２のセット）を構築することに焦点を当てず、むしろ、本発明の実施例は、ビデオ項目が、パケットのセットの一様なサイズを使用して配信され、パケットの各そのようなセットが、一様でない比Ｒ１及びＲ２の上記で説明された方式を利用するように、一様なセット・サイズ（たとえば、図示の例では、セットごとに９つのパケットの一様なサイズ、又はセットごとにＬバイトの一様なサイズ）を有するパケットのセットを構築することに焦点を当てる。

【0023】

いくつかの実施例は、随意に、システムが、１４個以下のパケット、又は１５個以下のパケット、又は１６個以下のパケットなど、フレームごとに生成されることを可能にされるパケットの数の上界を定義及び／又は利用及び／又は執行する限り、ビデオ・フレームごとの他と異なる（ｄｉｆｆｅｒｅｎｔｉａｌ）又は一様でない数のパケットを利用し得る。したがって、たとえば、ビデオ・フレームごとに１４個以下のパケットの上限を利用するとき、第１のビデオ・フレームが８つのパケットによって表され得、第２のビデオ・フレームが１４個のフレームとして表され得、第３のビデオ・フレームが１２個のパケットによって表され得、以下同様であり、フレームごとに１５個又は１６個又は１７個のパケットによって表されるビデオ・フレームがない。システムによって及び／又は送信エンティティによって設定される上界又は上限は、受信側デバイスに伝達又は通知され得るか、或いは受信側デバイスにおいてハード・コーディング又はソフト・コーディングされ得、それにより、受信側デバイスが、限定されたサイズのバッファ又はメモリ領域を割り振ること及び利用することを可能にし、そのようなバッファがオーバーフロー又はアンダーランしないことを保証する。たとえば、フレームごとに１５個以下のパケットの制限を定義することは、受信側エンティティが、１５個のパケットのみを収容するバッファを定義すること及び安全に利用することを可能にし得る。いくつかの実装形態では、システムのレイテンシは受信機バッファ・サイズに依存し得、したがって、そのようなサイズを制限又は限定することは、システムのレイテンシを減少させることに寄与し得る。

【0024】

例示的な実施例では、各パケットは、パケットごとに１，４００バイトなど、一様なサイズを有し、各パケットのバイト１～２０が、サブフレームに関するパケット番号及びヘッダ情報を搬送し、各パケットのバイト２１～２００が、粗いビデオ・データを搬送し、各パケットのバイト２０１～１，４００が精細ビデオ・データを搬送する。粗いビデオ・データについて、リード－ソロモン誤り訂正は、たとえば、リード－ソロモン・ワードごとに９バイトの一様な長さを有するリード－ソロモン・ワードを利用し得る。たとえば、パケット１０１～１０５の粗いビデオ・データ（たとえば、５×１８０＝９６０バイト）はリード－ソロモン・エンコーダに供給され、リード－ソロモン・エンコーダは、９×１８０＝１，６２０バイトにわたり、パケット１０６～１０９中の粗いビデオ・データのために予約されたパケット・セグメントに記憶される、リード－ソロモン・ワードを生成する。同様に、精細ビデオ・データについて、リード－ソロモン誤り訂正は、たとえば、リード－ソロモン・ワードごとに９バイトの一様な長さを有するリード－ソロモン・ワードを利用し得、パケット１０１～１０８の精細ビデオ・データ（たとえば、８×１，２００バイト）はリード－ソロモン・エンコーダに供給され、リード－ソロモン・エンコーダは、９×１，２００＝１０，８００バイトにわたり、パケット１０９中の精細ビデオ・データのために予約されたパケット・セグメントに記憶される、リード－ソロモン・ワードを生成する。

【0025】

たとえば、粗いデータのコーディング・レートは５／９であり、前述のように、合計９６０バイトの粗いデータがある。ただし、ＲＳワード長は９０バイト（たとえば、データの元の５０バイト＋冗長データの４０バイト）であり、１６２０／９０＝１８であるので、合計１８個のＲＳワードがある。いくつかの実施例では、冗長データのすべての４０バイトは、詳細には、ビデオ・フレームの９つのパケットの全体にわたって散乱するのではなく、ビデオ・フレームの９つのパケットのセットの最後の４つのパケット中に位置する。いくつかの実施例では、随意に、９つのパケットのセットの各パケットの粗いデータ部分は、粗いビデオ・データ又は粗いビデオ・データのＲＳ冗長のいずれかを含んでいるが、同じパケット中に両方は含まれていない。

【0026】

同様に、精細データに関して、８／９のコーディング・レートにおいて、冗長データ（ＲＳコード）のすべてのバイトは、詳細には、ビデオ・フレームの９つのパケットの全体にわたって散乱するのではなく、ビデオ・フレームの９つのパケットのセットの最後のパケット中に位置する。いくつかの実施例では、随意に、９つのパケットのセットの各パケットは、精細ビデオ・データ又は精細ビデオ・データのＲＳ冗長のいずれかを含んでいるが、同じパケット中に両方は含まれていない。

【0027】

本出願人は、単一のビデオ・フレームに対応する、Ｎ＝９つのパケットの同じセット中の、又は同じＵＤＰ／ＩＰデータグラム中の、パケットのヘッダ情報に関して、また別の異なる第３のコーディング・レート（Ｒ３）が利用され得ることをも了解している。たとえば、単一のビデオ・フレームはＳ個の領域又はサブフレーム（たとえば、図４に例示されているように、２４個の領域、又は２４個のサブフレーム）に分割され、各そのような領域又はサブフレームは別々に符号化され得、ヘッダに記憶されたデータは、ヘッダ情報が、特定のフレームのどの領域又はサブフレームが到着した又は消失したか、或いは、どの粗いデータ又は精細データが、（１つ又は複数の）特定のフレームのどの領域又はサブフレームに対応するかを決定するために、利用され得るので、受信側デバイス又はそれのデコーダにとって極めて重要であり得る。

【0028】

したがって、セット１００中に例示されているように、パケット１０１～１０３中でヘッダ情報のために予約されたパケット部分は、実際、そのフレームのサブフレームに関する前記情報を記述する元の又は有用なヘッダ情報を記憶及び搬送し得るが、次の４つのパケット（パケット１０４～１０７）中でヘッダ情報のために予約されたパケット部分は、実際のヘッダ情報を記憶せず、むしろ、それらは、代わりに、パケット１０１～１０３に記憶された３つのヘッダ・データ項目についてのリード－ソロモン誤り訂正コードを記憶する。たとえば、ヘッダ情報について、リード－ソロモン誤り訂正は、９バイトの一様な長さを有するリード－ソロモン・ワードを利用し得る。パケット１０１～１０３のヘッダ情報（たとえば、３×２０＝６０バイト）はリード－ソロモン・エンコーダに供給され、リード－ソロモン・エンコーダは、４×２０＝８０バイトにわたるリード－ソロモン・コードを生成し、それらの８０バイトのリード－ソロモン・パリティ・データは、パケット１０４～１０７中のヘッダ情報のために予約されたパケット・セグメントによって記憶及び搬送される。したがって、９つのパケットの単一のセット内のコーディング・レート（Ｒ３）は、３／７のコーディング・レートであり得るか、又は他の好適な値であり得、特に、第３のコーディング・レートＲ３は、１よりも小さいかそれに等しい、又は１より小さい、又は０．９０よりも小さい、又は０．８０よりも小さい、又は０．７５よりも小さい、又は０．６７よりも小さい、又は０．６０よりも小さい、又は０．５０よりも小さい。

【0029】

いくつかの実施例では、パケット１０８～１０９のヘッダ・パケット部分は、未使用のままであり得るか、又はヌル値で満たされ得る。他の実施例では、随意に、３：９のコーディング・レートＲ３が利用され得、したがって、パケット１０１～１０３の３つのヘッダ部分が、実際のヘッダ情報を記憶し、パケット１０４～１０９の６つのヘッダ部分が、対応するリード－ソロモン誤り訂正データを記憶して、それにより、（パケット１０１～１０３中で搬送され、パケット１０４～１０９中で誤り保護される）ヘッダ情報が受信側デバイスにおいて正しく復号される確率を、さらに増加させる。

【0030】

本発明のいくつかの実施例は、各ビデオ・フレームと、少なくとも粗いビデオと、また可能な場合、精細化されたビデオとが、特定のフレームのデータグラムのＵＤＰ／ＩＰの一部が受信側デバイスに到着しなかった場合でも、受信側デバイスにおいて復号可能であることを保証するために、複数の保護機構を利用し得る。例示的な実装形態では、送信の対象であるビデオは、６０フレーム毎秒（ＦＰＳ：ｆｒａｍｅｓ ｐｅｒ ｓｅｃｏｎｄ）のフレーム・レートを有し、したがって、各フレームは１，０００／６０＝１６．６７ミリ秒に対応する。送信デバイスは、各フレームを符号化するために最高９つのパケットが必要とされるという仮定又は推定に基づいて動作し得るが、送信デバイスは、一般に、特定のフレームが、ビデオ・データ（そのフレームの粗いビデオ・データ及び精細ビデオ・データ）を十分に搬送するために（たとえば）１０個のパケットを必要とすることを予測することが可能でないことがある。受信側デバイスは、単一のフレームについての完全なデータが、１６．６７ミリ秒ごとに又は約１６ミリ秒ごとに受信されるべきであるという、仮定に基づいて又は構成に基づいて、動作し得る。したがって、システム（送信デバイス及び受信デバイス）は、単一のフレームが、ビデオ・フレームごとの計画された９つのパケットではなく、１０個又は１１個のパケット上で搬送されることを必要とする、予期しないイベントが発生した場合でも、低レイテンシを保証するために１つ又は複数の保護機構を利用する必要があり得る。そのような状況では、送信デバイスは、各ビデオ・フレームごとに厳密に９つのパケットのみが送信され、それらの９つのフレームのうちのいくつかが失われ、受信側デバイスに到着しない場合でも、ビデオ・フレーム（たとえば、少なくともそれの粗いバージョンと、また場合によっては、それの精細化されたバージョンと）を正しく復号するのに十分な情報をそれらのパケット内で搬送することを保証するように、動作する。

【0031】

第１の保護機構として、一般に、粗いビデオ・データのために予約されるパケット部分のサイズが、一般に精細ビデオ・データのための予約である隣接する（同じパケットの）パケット部分のサイズという犠牲を払って増加され、それにより、フレームは、低減された量の精細ビデオ・データを（同じパケット中で）搬送しながら、増加された量の粗いビデオ・データを搬送することが可能になる。したがって、参照符号Ｚ８の下の右向きの湾曲した矢印によって図に指示されるように、粗いデータ・パケット部分と精細データ・パケット部分との間の境界であるパケット１０１中の垂直線は、右側に動的に移動（又はプッシュ、又はシフト）され、（たとえば）拡大又は増加されたサイズの粗いパケット部分と低減されたサイズの精細パケット部分とを表す破線垂直線で図に指示さるロケーションに位置することになる。これは、そのフレームの少なくとも粗いビデオ・データを配信することが、そのような配信が、そのフレームの精細ビデオ・データの一部（又はすべて）という犠牲を払う場合でも、より重要であることを反映する。したがって、この第１の保護機構は、フレームごとの固定された又はあらかじめ定義された数のパケットが、粗いビデオ・データの全体及び精細ビデオ・データの全体（及びそれらの両方についてのリード－ソロモン・パリティ情報の全体）を送信するには十分でない場合、一般に、そのフレームの精細ビデオ・データという犠牲を払って粗いビデオ・データを搬送するために予約又は指定された、パケットのうちの１つ又は複数中のスペース量が、そのフレームの精細ビデオ・データを搬送することに再割り当てされることになる、と決定する。

【0032】

第２の保護機構では、送信デバイスは、９つのパケット１０１～１０９のセットでは、元のプラン又は通常のプランが、精細ビデオ・データを実際搬送するために、精細ビデオ・データのために予約された（パケット１０１～１０８中の）８つのパケット部分を利用することと、パケット１０１～１０８の精細ビデオ・データについてのリード－ソロモン・パリティ情報を搬送するための第９のパケット（パケット１０９）の精細ビデオ・データ・パケット部分を利用することとであったことを、認識している。しかしながら、一方では、精細データの増加された量、他方では、上記で説明された第１の保護機構の動作により、送信デバイスは、それが現在、精細ビデオ・データを搬送するための（パケット１０１～１０８中の、又はそれらのうちの少なくとも１つ中の）低減されたサイズのパケット部分を有することを、認識している。したがって、第２の保護機構として、そのような状況では、第９のパケット（パケット１０９）の精細ビデオ・データ・パケット部分は、今度は、それの元の目的のために、すなわち、精細ビデオ・データのリード－ソロモン・パリティ情報を搬送するのではなく、精細ビデオ・データを搬送するために利用される。したがって、この第２の保護機構は、フレームごとの固定された又はあらかじめ定義された数のパケットが、精細ビデオ・データの全体及び精細ビデオ・データについてのリード－ソロモン・パリティ情報の全体を送信するには十分でない場合、精細ビデオ・データが、それのリード－ソロモン・パリティ情報よりも優先し、精細ビデオ・データが、通常ならば、精細ビデオ・データのリード－ソロモン・パリティ情報を搬送するために指定又は予約される、パケット部分中で搬送される、と決定する。

【0033】

第３の保護機構では、フレームごとの固定された又はあらかじめ定義された数のパケットが、粗いビデオ・データの全体及び精細ビデオ・データの全体、並びにそれらの両方についてのリード－ソロモン・パリティ情報の全体を送信するには十分でない場合、精細ビデオ・データについてのリード－ソロモン・パリティ情報は、そのフレームのこれらのパケット中でまったく送信されず、精細ビデオ・データのリード－ソロモン・パリティ情報の廃棄が、依然として、そのフレームについての精細ビデオ・データの送信を可能にするには十分でない場合、精細ビデオ・データは、廃棄され、このフレームについてのパケットのこのセット中で送信されない、すなわち、そのフレームの精細ビデオ・データの全体が、それらの９つのパケットから除外され、このフレームについて送出されないか、又は、代替的に、そのフレームについての精細ビデオ・データの少なくとも一部（たとえば、このフレームの２４個のサブフレームの中からの少なくともＳ個のサブフレームについての精細ビデオ・データ）が、それらの９つのパケットから除外され、そのフレームについて送信されないかのいずれかである。いくつかの実施例では、精細ビデオ・データは、９つのパケットのセット内に直列に配列され、したがって、（たとえば）最初に、送信デバイスは、９つのパケットから、サブフレーム２４の精細ビデオ・データを廃棄又は除外し、次いで、送信デバイスは、９つのパケットから、サブフレーム２３の精細ビデオ・データを廃棄又は除外し、以下同様であり、受信側デバイスは、依然として、それらのサブフレームの少なくとも粗いバージョンを受信及び復号及び表示することが可能であり得、精細ビデオ・データが除外されなかった（その同じフレームの）１つ又は複数のサブフレームの少なくとも、精細化されたバージョン（たとえば、サブフレーム１についての精細ビデオ・データ、サブフレーム２についての精細ビデオ・データ、サブフレーム３についての精細ビデオ・データ、以下、サブフレームのさらなる精細ビデオ・データが除外されたカットオフ・ポイントまで同様である）を、受信及び復号及び表示することが可能であり得る。

【0034】

第４の保護機構では、消失した粗いビデオ・データ及び／又は消失した精細ビデオ・データであろうと、消失したビデオ・データのリード－ソロモン再構築が、依然として、受信側デバイスにおいて実施されて、それにより、９つのパケットのセット中に（リード－ソロモン・パリティ情報が含まれていた場合）含まれていたリード－ソロモン・パリティ情報に基づいて、消失した粗いビデオ・データ及び／又は消失した精細ビデオ・データの１つ又は複数の部分（又は全体）が再構築され得る。これは、たとえば、９つのパケットのセットが、精細ビデオ・データについての及び／又は粗いビデオ・データについてのリード－ソロモン・パリティ情報の少なくとも一部を搬送する限り、実施され得る。

【0035】

いくつかの実施例では、受信側デバイス又はそれのデコーダは、特定のフレームの１つ又は複数のＵＤＰ／ＩＰパケットが消失した及び／又は到着せず、したがって、そのビデオ・フレームのサブフレームのうちのいくつかについて、細かいビデオ・データは再構築され得ないが、同じサブフレームについての粗いデータは再構築され得る、と決定し得る。そのような場合、デコーダは、細かいデータが消失したサブフレームの非圧縮バージョンを再構築するために、粗いデータのみを使用し得る。さらに、後のフレームについて、デコーダは、影響を及ぼされたサブフレームについて、これらのサブフレームの精細データが、後のフレーム中で正しく到着した場合でも、粗いビデオ・データのみを使用し続け得る。これは、いくつかの圧縮規格では、進行フレームが適切に復号されなかった場合、Ｐフレームが復号され得ないので、実施され得る。

【0036】

本発明のいくつかの実施例は、各ヘッダが、同じ、一定の数のパケットを有する（又は占有する）ように、ビデオ・ヘッダを利用し得るが、ビデオ・ペイロード（粗いビデオ・データ、及び精細ビデオ・データ）は、一定でない数のパケットを占有し、これらのタイプの情報（ヘッダ、粗いビデオ・データ、精細ビデオ・データ）の各々は、それ自体のリード－ソロモン誤り訂正情報で別々に保護され、これは、その単一のビデオ・フレームのパケットの全体にわたって散乱されるのではなく、その単一のビデオ・フレームのパケットのセット中の、各データ・タイプの終端部分において記憶される。

【0037】

いくつかの実施例では、フレームごとのパケットの数は、各ビデオ・フレームが、フレームごとのパケットのあらかじめ定義された上界を超えない数のパケットによって表される限り、同じビデオのフレームの間で変動し得る。上界は、たとえば、フレームごとに最高１１個又は１４個又は１５個のパケットとしてあらかじめ定義され得る。デコーダ・バッファは、フレームごとのパケットの上界限界を収容するのに十分に大きくなることになるが、より大きい受信機バッファがシステムのレイテンシに悪影響を及ぼし得るので、それよりも大きくなる必要はない。例示的な実装形態では、システムは、ビデオ・フレームごとに最高１５個のパケットの限界を利用する。受信側サイドにおいて、受信側デバイスは、最高１５個のパケットを記憶することが可能であるバッファを定義及び利用し、そのような受信機バッファは、１６個の（又はそれ以上の）パケットを記憶するための容量を有する必要がない。送信機サイドにおいて、符号化データが長すぎ、フレームごとに１５個のパケットの制約に適合しない場合、送信エンティティは、生成された最初の１５個のパケットのみを送り、残りのパケットを廃棄し、フレームごとに１５個よりも多いパケットを送らず、受信側エンティティは、ビデオ・フレーム、少なくともそれの粗いバージョン、及び、またできる限り、それの精細化されたバージョンを復号又は再構築するために、上記で説明された保護機構のうちの１つ又は複数を利用することになる。

【0038】

たとえば、ビデオ・エンコーダは、１つの符号化ビデオ・フレームが６，５００バイトを必要とし得、それの直後の符号化ビデオ・フレームが８，９００バイトを必要とし得るので、各ビデオ・フレームの（たとえば、バイト単位の）サイズが事前に容易に予測され得ないように、符号化ビデオを生成し得る。本出願人は、低レイテンシを達成するために、大きいサイズのバッファの利用を回避することが有益であり得ることを、了解している。したがって、本発明のシステム及び方法は、各フレームのビデオ符号化時に、必ずしも次の（１つ又は複数の）フレームの符号化又は（１つ又は複数の）他のフレームの符号化を待つことなしに、及び／或いは、現在符号化されているフレームのサイズに、又は（１つ又は複数の）他のフレーム（たとえば、すでに符号化されたフレーム、及び／又は符号化されることになるフレーム）のサイズに依存することなしに、送信デバイスによって（１つ又は複数の）パケットのセットが生成及び送信されるように、動作し得る。

【0039】

いくつかの実施例は、リード－ソロモン・パリティ・データについての特定のあらかじめ定義された一様なサイズを事前に定義することによって動作し得、たとえば、上記に示された例では、粗いビデオ・パリティ・データは、９つのパケットのセット中の４つのパケットの粗いパケット部分を占有することになり（粗いコーディング・レートＲ１＝４／９）、精細ビデオ・パーティ・データは、９つのパケットの同じセット中の１つの単一のパケットの精細パケット部分を占有することになり（精細コーディング・レートＲ２＝８／９）、ヘッダ情報は、実際のヘッダ情報のための３つのヘッダ部分と、実際のヘッダ情報のリード－ソロモン誤り訂正データのためのさらに４つのヘッダ部分との内部分割を伴う、７つのパケットのヘッダ・パケット部分を占有する（ヘッダ・コーディング・レートＲ３＝３／７）。送信エンティティは、必ずしも、実際の粗いデータ及び／又は実際の精細データを記憶するために使用される（ビデオ・フレームごとの）パケットの数を事前に決定する必要があるとは限らず、これは、送信エンティティが、フレームごとに、フレームごとのパケットのあらかじめ定義された上界値よりも多いパケットを送信しない限り、（１つ又は複数の）フレームが符号化されるとき、動的に又は選択的にオンザフライで決定され得る。むしろ、送信エンティティは、ヘッダ情報が、常に、パケットのセットにわたって、（上記で説明された３／７のヘッダ・コーディング・レートをもつ）７つのパケットの７つのヘッダ部分など、固定されたサイズを占有することになることを、受信側エンティティに通知し得るか、又は、さもなければ、受信側エンティティは、そのような指示を有するように構成され得る。

【0040】

本発明のいくつかの例示的な実施例による、フレーム・グループ化を例示する概略図である図２が参照される。ＵＤＰ／ＩＰ上でのＨ．２６５ビデオ送信のロバストネスを改善する様式で、３つのグループ又は３つのベクトルのセット２００が生成される。

【0041】

「粗いビデオ・データ・ベクトル」又は「粗いビデオ・データ・グループ」と呼ばれることもある、第１のグループ又はベクトル２０１では、粗いビデオ・データは、単一のフレームのＭ個のサブフレームについて累積される。たとえば、符号化されており、２４個のサブフレーム（フレーム領域）に分割される、特定のフレームに関して、第１のグループ２０１は、サブフレーム１についての粗いビデオ・データを、及びその後に続く、サブフレーム２についての粗いビデオ・データを、以下同様に、その第１のグループ２０１を終えるサブフレーム２４についての粗いビデオ・データまで、含む。これらのサブフレームの粗いビデオ・データの（たとえば、バイト単位の）サイズは、そのサイズが、（一般に、同一でないコンテンツであり得る）それらのサブフレームの各々中に現れるコンテンツに依存するので、固定されず、一様でないことに留意されたい。

【0042】

サブフレームは、各サブフレームの復号が、（その同じビデオ・フレームの、及び任意の他のビデオ・フレームの任意の他のサブフレームの）他のサブフレームの復号から独立するような、独立した様式で符号化され得る。サブフレームを復号することのこの独立は、フレーム間予測について、各サブフレームについての参照画像が、他のフレーム中の同じサブフレームのエリアのみを含み、（１つ又は複数の）他のフレーム中の（１つ又は複数の）他のサブフレームのエリアを含まない、という特徴を含み得るか、又はその特徴を利用し得る。

【0043】

同様に、「細かいビデオ・データ・ベクトル」又は「細かいビデオ・データ・グループ」と呼ばれることもある、第２のグループ又はベクトル２０２では、細かい（又は精細）ビデオ・データは、単一のフレームのサブフレームについて累積される。たとえば、符号化されており、２４個のサブフレーム（フレーム領域）に分割される、特定のフレームに関して、第２のグループ２０２は、サブフレーム１についての細かいビデオ・データを、及びその後に続く、サブフレーム２についての細かいビデオ・データを、以下同様に、その第２のグループ２０２を終えるサブフレーム２４についての細かいビデオ・データまで、含む。これらのサブフレームの細かいビデオ・データの（たとえば、バイト単位の）サイズは、そのサイズが、（一般に、同一でないコンテンツであり得る）それらのサブフレームの各々中に現れるコンテンツに依存するので、固定されず、一様でないことに留意されたい。

【0044】

また、第１のグループ２０１（粗いビデオ・データ・グループ）の全体の（たとえば、バイト単位の）累積サイズは、第２のグループ２０２（精細ビデオ・データ・グループ）の全体の（たとえば、バイト単位の）累積サイズとは異なることに留意されたい。さらに、２つの異なるフレームについて、各フレームの（たとえば、バイト単位の）累積サイズは、一般に異なり、固定されない。

【0045】

ヘッダ・グループ２０３（又はヘッダ・ベクトル）は、現在フレームのサブフレーム１の粗いビデオ・データの（たとえば、バイト単位の）サイズの指示Ｌｃ（１）、次いで、現在フレームのサブフレーム２の粗いビデオ・データの（たとえば、バイト単位の）サイズの指示Ｌｃ（２）、以下同様に、（たとえば、２４サブフレームからなるフレームの最後のサブフレームであるサブフレーム２４の粗いデータのサイズを指示するＬｃ（２４）までの）そのフレームの各後のサブフレームの粗いデータの（たとえば、バイト単位の）サイズの指示、及び現在フレームのサブフレーム１の精細ビデオ・データの（たとえば、バイト単位の）サイズの指示Ｌｆ（１）、現在フレームのサブフレーム２の精細ビデオ・データの（たとえば、バイト単位の）サイズの指示Ｌｆ（２）、以下同様に、（たとえば、２４サブフレームからなるフレームの最後のサブフレームであるサブフレーム２４の精細データのサイズを指示するＬｆ（２４）までの）そのフレームの各後のサブフレームの精細データの（たとえば、バイト単位の）サイズの指示など、精細ビデオ・データについてのインジケータの同様のアグリゲーションを含み得る。したがって、２４個のサブフレームに分割されたフレームについて、ヘッダ情報は、各粗いビデオ・データと、次いで、各精細ビデオ・データとの（たとえば、バイト単位の）サイズの４８個のインジケータのリストを含み得る。

【0046】

ヘッダ部分に関して、本発明の実施例は、以下の特徴を利用し得る。第１に、ヘッダ部分が存在し、そのようなヘッダは、（パケットのうちのいくつか又はそれ以上が受信側デバイスに到着しない場合でも）送信されたサブフレームの粗いデータ及び精細データのマップとして動作し、そのようなヘッダが、到着し、影響を受けないサブフレームに関係する、データの利用を可能にし得るので、ＲＳデコーダが失敗した場合でも、到着した精細データ及び／又は到着した粗いデータを少なくとも部分的に利用する能力を受信側デバイスに提供する、という事実。第２に、ヘッダ部分に提供される保護は、精細部分に提供される保護よりも大きく（たとえば、Ｒ３＜Ｒ２、さらにはＲ３＜＜Ｒ２）、ヘッダ部分に提供される保護は、粗い部分に提供される保護と少なくとも同じか、又はそれよりも良好であり（たとえば、Ｒ３＜Ｒ１、又は、せいぜいＲ３＝Ｒ１）、したがって、システムは、精細データ（又はそれのいくつかの部分）が復号可能でない場合でも、及び場合によっては、粗いデータ（又はそれのいくつかの部分）が復号可能でない場合でも、重要なヘッダ・データが復号可能であることになることを保証する。

【0047】

いくつかの実施例では、ヘッダ部分は、必ずしも、すべてのヘッダ・フレームについて一様である固定されたサイズを有するとは限らず、むしろ、ヘッダ部分は、すべてのフレームのすべてのパケットのすべてのヘッダにわたって、固定された又は一様なサイズを有する、少なくとも１つのサブ部分を有し得る。たとえば、例示的な実装形態では、ヘッダ部分は、２つのサブ部分、すなわち、（ｉ）固定されない又は一様でないサイズ（たとえば、ビデオ・フレームごとに約１００バイト、又はパケットごとに約２０バイト、ただし、必ずしも、固定されたバイト長を有するとは限らない）を有し得、現在ビデオ・フレーム内のサブフレームのマッピングの情報を含む、「ＶＥヘッダ」サブ部分としても示される「ビデオ・エンコーダ・ヘッダ」サブ部分と、（ｉｉ）すべてのパケット及びすべてのフレームにわたって、固定された又は一様なサイズ（たとえば、ビデオ・フレームごとにちょうど８バイト）を有し、現在ビデオ・フレームに属するパケットの数を指示する、「Ｂｌｋヘッダ」サブ部分としても示される「ブロック・ヘッダ」サブ部分とを含み得る。ブロック・ヘッダ・サブ部分についてのリード－ソロモン・ワードのサイズは、ビデオ・エンコーダ・ヘッダ・サブ部分についてのリード－ソロモン・ワードの変化するサイズとは異なり、固定され、したがって、ブロック・ヘッダがその上で送信されるパケットの数は固定される。

【0048】

本発明のいくつかの例示的な実施例による、システム３００の概略図である図３が参照される。システム３００は、ワイヤレス通信リンク上で、及び、特に、ＩＰベース通信リンク上で又はＵＤＰ／ＩＰ通信リンク上で、受信側デバイス３２０と通信することが可能な送信デバイス３１０を備える。

【0049】

送信デバイス３１０は、受信側デバイス３２０に送信及び配信されることを意図されるソース・ビデオ又は入力ビデオ３１０を記憶又は受信する、又はそれへのアクセスを有する。送信デバイス３１０は、たとえば、ＨＥＶＣ又はＨ．２６５又はＨ．２６４－ＳＶＣ又は他の好適なビデオ圧縮規格を使用して、ソース／入力ビデオのビデオ符号化を実施する、ビデオ・エンコーダ３１１を備える。次いで、フレームの各グループが、同じ単一のＦＥＣワード又はＦＥＣコード又はリード－ソロモン・ワードを利用するように、フレーム・グループ化ユニット３１２がフレームのグループ化を実施し得る。パケット化ユニット及びＦＥＣエンコーダ／ＲＳエンコーダ３１３が、符号化フレーム・データのパケット化と、ＦＥＣコード又はＲＳワードの追加とをハンドリングする。送信機３１４が、受信側デバイス３２０にパケットを送信する。

【0050】

受信側デバイス３２０において、受信機３２１が着信パケットを受信し、必ずしもすべての送信パケットが受信機３２１において実際に受信されるとは限らない。したがって、消失したＵＤＰパケット検出器３２２が、到着パケットを追跡することと、パケット通し番号に基づいて、消失したパケットを検出することとを行うように動作し、１の値が、消失したパケットを指示し、０の値が、受信されたパケットを指示するような、連続するパケットを表すベクトルを利用する消去ベクトル生成器及びアップデータ３２３を随意に利用する。次いで、パケット化解除ユニット及びＦＥＣデコーダ／ＲＳデコーダ３２４が、データをパケット化解除することと、到着したパケットに対してＦＥＣ又はＲＳ復号を実施することとを行うように動作する。随意に、ＦＥＣデコーダは、消去指示を利用するように構成され得、たとえば、いくつかのＲＳデコーダは、それらのＲＳデコーダが消去指示を受信しないとき、最高ｆｌｏｏｒ（Ｎ－Ｋ）／２）個の誤りを訂正することができるが、それらのＲＳデコーダが、これらの誤りのロケーションに関する消去指示を与えられる場合、最高（Ｎ－Ｋ）個の誤りを訂正することができる。フレーム非グループ化ユニット３２５が、フレームのグループを個別フレームに非グループ化し、ビデオ・デコーダ３２６が、各そのようなフレームの復号（たとえば、ＨＥＶＣ又はＨ．２６５又はＨ．２６４－ＳＶＣ復号）を実施し、それにより、スクリーン又はモニタ又は他のディスプレイ・ユニットを介してユーザに出力又は表示され得る、出力ビデオ３２７を作り出す。

【0051】

システム３００のユニットの各々は、ハードウェア構成要素及び／又はソフトウェア構成要素として実装され得る。いくつかの実施例では、システム３００のユニット又はデバイスは、たとえば、プロセッサ、中央処理ユニット（ＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、デジタル信号プロセッサ（ＤＳＰ：Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、グラフィックス処理ユニット（ＧＰＵ：Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、処理コア、コントローラ、論理ユニット、メモリ・ユニット（たとえば、ランダム・アクセス・メモリ（ＲＡＭ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、フラッシュ・メモリ）、記憶ユニット（たとえば、ハード・ディスク・ドライブ、ソリッド・ステート・ドライブ、オプティカル・ドライブ）、入力ユニット（たとえば、キーボード、キーパッド、マウス、トラックボール、オーディオ・マイクロホン、タッチスクリーン）、出力ユニット（たとえば、スクリーン、タッチスクリーン、オーディオ・スピーカー）、電源（たとえば、バッテリー、電池、本線電力への接続）、１つ又は複数のワイヤード及び／又はワイヤレス・トランシーバ（たとえば、Ｗｉ－Ｆｉトランシーバ、Ｂｌｕｅｔｏｏｔｈトランシーバ、セルラー・トランシーバ）、デバイスの構成要素のいくつか又はすべてを一緒に保持するハウジング、ドライバ及びアプリケーションをもつオペレーティング・システム（ＯＳ：Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、並びに／或いは他の好適なハードウェア構成要素及び／又はソフトウェア構成要素など、他の好適な構成要素を備えるか、又はそれらを使用して実装され得る。

【0052】

本発明の実施例によれば、計算、動作及び／又は決定は、単一のデバイス内でローカルに実施され得るか、或いは、随意に生データ及び／又は処理されたデータ及び／又は処理結果を交換するために通信チャネルを利用することによって、複数のデバイスによって若しくは複数のデバイスにわたって実施され得るか、又は部分的にローカルに及び（たとえば、リモート・サーバにおいて）部分的にリモートで実施され得る。

【0053】

本発明のいくつかの追加の実施例が本明細書で説明され、それらの実施例は、随意に、前に説明された実施例の特徴及び／又は構成要素及び／又はステップと組み合わせられ得る。

【0054】

本出願人は、ビデオ・データが一連の静止画像フレームとして表され得ることを了解している。エンコーダは、フレーム間の類似度を記述する命令とともにフレーム間の差を記憶することによって、フレームを符号化し得る。命令は、概して動きによる、フレーム間の同様のデータの位置の差に関連する情報を含み得る。この差は、概して、動きベクトル及び予測誤りによって表現される。符号化フレーム及び／又は命令は、次いで、それらが復号され得、画像フレームが再構築され得る、デコーダに、エンコーダによって送られる。慣例は、認められたビデオ圧縮規格に関連する知られているビデオ圧縮フォーマットを使用して、ビデオ・フレームを符号化することであり、そのビデオ圧縮規格の最も普及しているものの１つは、ＩＴＵのＨ．２６５規格である。

【0055】

インターネット・プロトコル（ＩＰ）を使用してＨ．２６５符号化ビデオ・フレームを送ることは、概して、フレーム又はサブフレームをパケット化することと、ユーザ・データグラム・プロトコル（ＵＤＰ）又は伝送制御プロトコル（ＴＣＰ）を使用してエンコーダにパケットを送ることとを伴う。ＵＤＰは、最小限のプロトコル機構をもつ単純な無接続通信モデルを使用し、これは、レイテンシ低減を重要視し、ＵＤＰを、パケットをドロップすることが、ＴＣＰによって必要とされる再送信により遅延されたパケットを待つことよりも好ましい、時間敏感アプリケーションにとって好適にする。

【0056】

Ｈ．２６５符号化ビデオ・フレームは、３つのタイプのフレーム（又はサブフレーム）、すなわち、Ｉフレームと、Ｂフレームと、Ｐフレームとに分割され得る。Ｉフレームは、一般にイントラコード化フレーム（イントラフレーム）として参照され、他のフレームと無関係にコーディングされる。Ｐフレームは、一般に予測インターコード化フレーム（インターフレーム）と呼ばれ、過去のＩフレーム及びＰフレームに関して符号化される。Ｂフレームは、一般に双方向予測インターフレームと呼ばれ、過去の及び将来のＩフレーム及びＰフレームに関して符号化される。

【0057】

本発明の一実施例によれば、ＵＤＰパケット中でビデオ・データを送信する方法であって、エンコーダにおいて、ビデオ・データを、単一のＩフレームと複数のＰフレームとを各々有するピクチャ・グループ（ＧＯＰ：ｇｒｏｕｐ ｏｆ ｐｉｃｔｕｒｅｓ）に符号化することと、ＵＤＰパケット中でＧＯＰの各フレーム又はサブフレームを送信することとを含む、方法が提供される。本方法は、デコーダにおいて、送信されたＵＤＰパケットのすべての受信を検査することと、送信されたＵＤＰパケットのすべての受信に応答してデコーダからエンコーダにフィードバックを送ることとをさらに含み得る。

【0058】

いくつかの実施例では、フィードバックはＡＣＫ（確認応答）メッセージを含み得る。随意に、ＡＣＫメッセージは、最後の受信されたフレームに関連するインデックス番号を含み得る。いくつかの実施例では、本方法は、各ＵＤＰパケット中に、送信されているフレーム又はサブフレームに関連するインデックス番号と、送信されるべき後続のＩフレーム又はＩサブフレームに関連するインデックス番号とを含めることをさらに含み得る。いくつかの実施例では、ＡＣＫメッセージを受信すると、エンコーダは、後続のＩフレーム又はＩサブフレームに関連するインデックス番号を、ＡＣＫメッセージ中のインデックス番号に関連する新しいインデックス番号と交換し得る。随意に、新しいインデックス番号は、複数のＰフレーム中のＰフレームの数を含み得る。いくつかの実施例では、本方法は、フィードバックに応答してＰフレーム又はＰサブフレームのみを送信することをさらに含み得る。

【0059】

本発明の一実施例によれば、ＵＤＰビデオ送信におけるパケット誤り隠蔽の方法であって、エンコーダにおいて、フレーム又はサブフレームに関連するＤＣＴタップをジグザグ順序で配列することと、ＤＣＴタップを量子化することと、量子化されたＤＣＴタップからフレーム又はサブフレームの第１の記述を作成することと、量子化されたＤＣＴタップからフレーム又はサブフレームの第２の記述を作成することと、別々のＵＤＰパケット中でデコーダに第１の記述と第２の記述とを送ることとを含む、方法が提供される。

【0060】

いくつかの実施例では、ＤＣＴタップを量子化することは、Ｑ１＜＜Ｑ２であるような２つの値Ｑ１及びＱ２を含み得る。いくつかの実施例では、第１の記述は、偶数タップについてのＱ１と、奇数タップについてのＱ２とを含み得る。代替的に、第１の記述は、奇数タップについてのＱ１と、偶数タップについてのＱ２とを含み得る。

【0061】

いくつかの実施例では、第１の記述中のＤＣＴタップは、量子化点．．．、－５、－３、－１、０、２、４、６．．．の周りで量子化され得る。いくつかの実施例では、第２の記述中のＤＣＴタップは、量子化点．．．、－６、－４、－２、０、１、３、５．．．の周りで量子化され得る。

【0062】

いくつかの実施例では、第１の記述中のＤＣＴタップは、量子化点．．．、－９、－６、－３、０、１、２、３．．．の周りで量子化され得る。いくつかの実施例では、第２の記述中のＤＣＴタップは、量子化点．．．、－３、－２、－１、０、３、６、９．．．の周りで量子化され得る。

【0063】

いくつかの実施例では、本方法は、デコーダにおいて、パケット誤り隠蔽のために第１の記述を使用することをさらに含み得る。本方法は、デコーダにおいて、パケット誤り隠蔽のために第２の記述を使用することをさらに含み得る。いくつかの実施例では、本方法は、デコーダにおいて、第１の記述中の量子化されたＤＣＴタップを第２の記述中の量子化されたＤＣＴタップと平均化するために、最大比合成（ＭＲＣ：Ｍａｘｉｍｕｍ－Ｒａｔｉｏ－Ｃｏｍｂｉｎｉｎｇ）を使用することをさらに含み得る。平均化することは加重平均化することを含み得る。

【0064】

いくつかの実施例では、本方法は、デコーダにおいて、第１の記述及び第２の記述を量子化点．．．、－２、－１、０、１、２、．．．の周りで復号することをさらに含み得る。

【0065】

いくつかの実施例では、第２の記述は、動きベクトルのみを含み得る。

【0066】

いくつかの実施例では、Ｈ．２６５ビデオ・データは、Ｉフレーム又はサブフレーム（Ｉ）と、Ｐフレーム又はサブフレーム（Ｐ）とから構成されるピクチャ・グループ（ＧＯＰ）、たとえば、ＩＰＰＰＰＩＰＰＰ．．．．．ＩＰＰＰＰに符号化され得る。以下では、便宜上、「フレーム」及び「サブフレーム」という用語は互換的に使用され得る。ＧＯＰ中の多くのＩフレームの使用は、それが、Ｐフレームによって構成されるペイロードよりも１０倍大きくなることさえある大きいペイロードを補い得るので、不利であり得る。一方、それは、Ｉフレームが、メモリを使用せずに復号され得るので、ロバストネスの利点を提供し、誤りからの回復が速くなる。通常、前のＩフレーム又はＰフレームに基づく、多くのＰフレームの使用は、それが、小さいコンパクトなペイロードを埋め合わせ得るので、有利であり得る。とはいえ、それは、誤り伝搬が次のＩフレームの開始まで広がり得るという欠点を有する。

【0067】

本出願人は、単一のＩフレームと、その後に続く、複数のＰフレームとからなるＧＯＰでは、選択されるＰフレームの数Ｍが、低ビット・レート、ただし長い誤り伝搬時間に寄与する、大きいＭと、高ビット・レート、ただし短い誤り伝搬時間に寄与する、小さいＭとの間のトレードオフを必要とすることを、了解している。出願人は、大きいＭによって提供される低ビット・レートと、小さいＭによって提供される短い誤り伝搬レートとを利用するために、ＧＯＰが、長い誤り伝搬時間を防ぐために、単一のＩフレーム（又はＩサブフレーム）と、その後に続く、比較的小さい数ＭのＰフレーム（又はＰサブフレーム）とを含み得るが、パケットが正常に受信されているというデコーダからのフィードバックを組み込むことによって、エンコーダが、Ｉフレームを送る必要なしにＰフレームを送信することを継続し得ることを、さらに了解している。

【0068】

ＵＤＰパケットはデコーダによって受信されないことがあり、ＵＤＰは、一般に、ＡＣＫメッセージを採用しない。したがって、出願人は、フィードバックを提供するための、各フレームのすべてのＵＤＰパケットが受信されたときに（又はサブフレームのすべてのパケットが受信されたときに）アプリケーション・レイヤ上でデコーダからエンコーダに送られ得る、ＡＣＫメッセージを導入している。

【0069】

各ＵＤＰパケットは、パケット中の現在フレームの数に関する情報を含み得、送信されるべき次のＩフレームのインデックス番号をさらに含み得る。ＡＣＫメッセージは、エンコーダによって受信されないことがあるか、又はある遅延を伴って到着し得るので、ＡＣＫメッセージの受信時に、エンコーダは、ＵＤＰパケット中の次のＩフレームのインデックス番号を、新しいインデックス番号と交換し得、新しいインデックス番号は、ＡＣＫが受信された最後の受信されたフレームのインデックス番号と、最後の受信されたフレームに続くＰフレームの数Ｍとを含み得る。エンコーダが、Ｍ個のＰフレームの送信に続く新しいＡＣＫメッセージを受信しない場合、エンコーダは、Ｉフレームを含む新しいＧＯＰを送信することに戻り得る。

【0070】

本出願人による上記の了解によって説明される方法の実装は、１つ又は複数の利益又は利点、たとえば、以下を提供し得る。

【0071】

（ａ）誤りがない限り、Ｐフレーム・パケットのみが送られ得る。

【0072】

（ｂ）ダウンロード・レイテンシとアップロード・レイテンシとの間につながり（ｃｏｎｎｅｃｔｉｏｎ）がないので、アップロード・レイテンシは比較的大きくなり得る。

【0073】

（ｃ）アップロード・フレームについての遅延要件は、比較的達成しやすいことがあるＭ個のフレームである。

【0074】

（ｄ）アップロードについてのパケット誤り率（ＰＥＲ：ｐａｃｋｅｔ ｅｒｒｏｒ ｒａｔｅ）は、Ｍ－１／Ｍによって表現され得、たとえば、７０％のＰＥＲが許容可能である。

【0075】

（ｅ）誤り伝搬は、Ｍ個のフレームに限定され得、平均誤り伝搬はＭ／２個のフレームに限定され得る。及び／又は

【0076】

（ｆ）Ｉフレーム・パケットとＰフレーム・パケットとの間の比は、ＵＤＰ ＰＥＲに従い得、したがって、ＵＤＰ ＰＥＲレートの変化がある場合、Ｉフレーム対Ｐフレーム比の変化もあり得る。

【0077】

ＰＥＲはＵＤＰの特性である。前方誤り訂正（ＦＥＣ）が使用され得るが、時々、ＦＥＣは失敗することがあり、それにより、代替として、前のフレームに基づく隠蔽方法を使用して、失われたパケットを補う。このタイプの隠蔽方法は、それが送信ペイロードを必要としないので、「ゼロ・オーバーヘッド隠蔽」と呼ばれることがある。しかしながら、隠蔽イベントは、１つのフレームよりも長くなり得、誤り伝搬により次のＩフレームまで継続し、隠蔽中に、ビデオ品質が妥当な品質に維持されることを必要とし得る。

【0078】

本出願人は、ゼロ・オーバーヘッド隠蔽に関連する問題が、別々のＵＤＰパケット中でビデオ・データの複数の記述を送信することによって克服され得ることを、さらに了解している。随意に、複数の記述は、各々がＵＤＰパケット中で送信される、２つの記述を含み得る。次いで、デコーダは、受信された場合、すべての送信パケットを使用し得るか、又は代替的に、本明細書で以下で説明され、以下で「小さいオーバーヘッド隠蔽」と呼ばれる、方法における、受信されたパケットのみを使用し得る。随意に、２つの記述のみが送信された場合、デコーダは、２つのＵＤＰパケットが受信された場合、２つの記述を使用し、１つのみが受信された場合、１つの記述のみを使用し得る。

【0079】

本発明の第１の実施例では、エンコーダは、ＤＣＴタップをジグザグ順序で配列し得、Ｑ１＜＜Ｑ２であるようにそれらの値Ｑを量子化し得、次いで、第１の記述が、偶数タップについてのＱ１と奇数タップについてのＱ２とを含み得、第２の記述が、奇数タップについてのＱ１と偶数タップについてのＱ２とを含み得る、２つの記述を作成し得る。２つの記述は、次いで、別々のＵＤＰパケット中で送られ得、１つの記述のみが到着したのか、両方の記述が到着したのかに基づいて、デコーダによって復号され得る。１つの記述のみが到着した場合、デコーダは、次いで、小さいオーバーヘッド隠蔽のためにその記述を使用し得る。両方の記述が到着した場合、デコーダは、加重平均を使用して第１の記述中のタップを第２の記述中のタップと平均化するために、最大比合成（ＭＲＣ）を使用し得る。各記述では、Ｑ２において量子化されたタップの大部分は、「０」に等しく、それにより、パケット・ペイロードの小さい部分を占有し得る。フレーム間予測では、エンコーダは、両方の記述が、デコーダによって受信され、参照画像を生成するためにＭＲＣを実施された、と仮定し得る。

【0080】

本発明の第２の実施例では、エンコーダは、ＤＣＴタップをジグザグ順序で配列し得、２つの記述、すなわち、第１の記述中の、点．．．、－５、－３、－１、０、２、４、６、．．．の周りで量子化されたＤＣＴタップの量子化値Ｑと、第２の記述中の、点．．．－６、－４、－２、０、１、３、５、．．．の周りで量子化されたＤＣＴタップの量子化値Ｑとを作成し得る。２つの記述は、別々のＵＤＰパケット中で送られ得、１つの記述のみが到着したのか、両方の記述が到着したのかに基づいて、デコーダによって復号され得る。１つの記述のみが到着した場合、デコーダは、次いで、小さいオーバーヘッド隠蔽のためにその記述を使用し得る。両方の記述が到着した場合、デコーダは、解像度をもつ量子化点．．．－２、－１、０、１、２．．．の周りで、受信された記述を復号し得る。各記述中の長さ（ペイロード）は、完全な記述（．．．－２、－１、０、１、２．．．）よりもはるかに小さいことに留意されたい。一般的なバジェットでは、タップごとの平均ビット・レートが１．５よりも低いとき、各記述の長さは、完全な記述の約１／２であり得ると推定され得る。

【0081】

本発明の第３の実施例では、エンコーダは、ＤＣＴタップをジグザグ順序で配列し得、２つの記述、すなわち、第１の記述中の、点．．．、－９、－６、－３、０、１、２、３、．．．の周りで量子化されたＤＣＴタップの量子化値Ｑと、第２の記述中の、点．．．－３、－２、－１、０、１、６、９、．．．の周りで量子化されたＤＣＴタップの量子化値Ｑとを作成し得る。２つの記述は、別々のＵＤＰパケット中で送られ得、１つの記述のみが到着したのか、両方の記述が到着したのかに基づいて、デコーダによって復号され得る。１つの記述のみが到着した場合、デコーダは、次いで、小さいオーバーヘッド隠蔽のためにその記述を使用し得る。両方の記述が到着した場合、デコーダは、解像度をもつ量子化点．．．－２、－１、０、１、２．．．の周りで、受信された記述を復号し得る。各記述中の長さ（ペイロード）は、完全な記述（．．．－２、－１、０、１、２．．．）よりもはるかに小さいことに留意されたい。一般的なバジェットでは、タップごとの平均ビット・レートが１．５よりも低いとき、各記述の長さは、完全な記述の約１／２であり得ると推定され得る。

【0082】

本発明の第４の実施例では、エンコーダは、Ｐフレームについて２つの記述を作成し得る。第１の記述は完全な記述を含み得、第２の記述は、残差のＤＣＴなしの動きベクトル（ＭＶ：ｍｏｔｉｏｎ ｖｅｃｔｏｒ）を含み得る。２つの記述は、別々のＵＤＰパケット中で送られ得、１つの記述のみが到着したのか、両方の記述が到着したのかに基づいて、デコーダによって復号され得る。１つの記述のみが到着した場合、デコーダは、次いで、小さいオーバーヘッド隠蔽のためにその記述を使用し得る。第１の記述が到着した場合、デコーダはその記述を使用し得る。第１の記述が到着しない場合、デコーダは、ＭＶについて第２の記述を使用し得、残差について「０」を使用し得る。随意に、第２の記述が１００％オーバーヘッドであるので、第２の記述におけるＭＶ解像度は、第２の記述のビット・レートを低減するために、第１の記述におけるＭＶ解像度よりも低くなり得る。

【0083】

本発明のいくつかの例示的な実施例による、ＵＤＰパケットを使用するビデオ送信におけるビット・レート及び誤り伝搬を最小限に抑える例示的な方法のフロー・チャートである図５が参照される。本方法は、より多くのステップを用いて又はより少ないステップを用いて、及び／或いは、随意に、異なる順序で配列されたステップを用いて実施され得る。

【0084】

ステップ５００において、単一のＩフレーム（Ｉ）と複数のＰフレーム（Ｐ）とをもつＧＯＰが符号化され得る。随意に、全フレームの代わりに、サブフレームが使用され得る（Ｉサブフレーム及びＰサブフレーム）。Ｐフレームの数Ｍは、長い伝搬誤りを回避するために、比較的小さく選択され、たとえば、Ｍ＝４であり得る。すなわち、Ｍ＝４を使用することが、ＧＯＰ＝ＩＰＰＰＰを与え、３の場合、ＧＯＰ＝ＩＰＰＰＰＩＰＰＰＰＩＰＰＰＰを与える。

【0085】

ステップ５０２において、各フレーム（又はサブフレーム）は、ＵＤＰパケットにパケット化され得る。各パケット・ペイロードは、ペイロード中に現在フレーム（又はサブフレーム）に関連するインデックス番号を含み得る。ペイロードは、（後続のＧＯＰ中で）送信されるべき次のＩフレーム（又はサブフレーム）に関連するインデックス番号をも含み得る。

【0086】

ステップ５０４において、すべてのＵＤＰパケットがデコーダに送られ得る。

【0087】

ステップ５０６において、デコーダは、すべてのＵＤＰパケットが受信されたことを検査し得る。はいの場合、１０８に進む。いいえの場合、デコーダは、新しいフレーム（又はサブフレーム）を待つことを継続する。

【0088】

ステップ５０８において、デコーダは、フレーム又はサブフレームのすべてのパケットが受信されたことを指示するＡＣＫメッセージを、エンコーダに送り得る。

【0089】

ステップ５１０において、ＡＣＫメッセージが受信されたかどうかを確かめるために、エンコーダにおいて検査が行われ得る。はいの場合、ステップ５１２に進む。いいえの場合、ステップ５１４に進む。

【0090】

ステップ５１２において、エンコーダはパケット中で、送信されるべき次のＩフレームのインデックス番号（ＮｎｅｘｔＩ）を、受信され、それについてＡＣＫメッセージが受信された最後のフレーム（又はサブフレーム）に関連するインデックス番号（Ｎ）、及びＡＣＫメッセージに関連するフレームに続いて送られているＰフレームの数４と、交換し得る。エンコーダは、ＡＣＫメッセージが、Ｉフレームを送ることなしにデコーダから受信されている限り、４つのＰフレーム（又はサブフレーム）のグループを送ることを継続し得る。

【0091】

ステップ５１４において、エンコーダは、４つのＰフレームを送信するために終了する。これに続いて、ステップ５０２に進む。送信されるべき後続のフレームは、次のＧＯＰに関連するＩフレームであり得る。

【0092】

本発明のいくつかの例示的な実施例による、ＵＤＰパケットを使用するビデオ送信における小さいオーバーヘッド隠蔽を実施する例示的な方法のフローチャートである図６が参照される。本方法は、より多くのステップを用いて又はより少ないステップを用いて、及び／或いは、随意に、異なる順序で配列されたステップを用いて実施され得る。

【0093】

ステップ６００において、フレーム（又はサブフレーム）に関連するＤＣＴタップは、エンコーダによってジグザグ順序で配列され得る。

【0094】

ステップ６０２において、ＤＣＴタップは、２つの値Ｑ１及びＱ２で量子化され得、ここで、Ｑ１＜＜Ｑ２である。随意に、Ｑ２は、Ｑ１の少数整数倍（ｆｒａｃｔｉｏｎａｌ ｉｎｔｅｇｅｒ ｍｕｌｔｉｐｌｅ）、たとえば、Ｑ２＝３．５×Ｑ１である。

【0095】

ステップ６０４において、エンコーダは、偶数タップについてのＱ１と奇数タップについてのＱ２とを使用して、フレーム（又はサブフレーム）の第１の記述を作成し得る。

【0096】

ステップ６０６において、エンコーダは、奇数タップについてのＱ１と偶数タップについてのＱ２とを使用して、フレーム（又はサブフレーム）の第２の記述を作成し得る。

【0097】

ステップ６０８において、第１の記述と第２の記述とは、各々パケット化され、別々のＵＤＰパケット中でデコーダに別々に送られ得る。

【0098】

ステップ６１０において、デコーダは、第１の記述及び第２の記述が到着したかどうかを確かめるために検査し得る。それらの記述のうちの１つのみが到着した場合、ステップ６１２に進む。両方が到着した場合、ステップ６１４に進む。

【0099】

ステップ６１２において、デコーダは、小さいオーバーヘッド隠蔽を実施するために、受信された記述（第１又は第２）を使用し得る。

【0100】

ステップ６１４において、デコーダは、小さいオーバーヘッド隠蔽を実施するために、両方の受信された記述を使用し得る。デコーダは、両方の記述中のＤＣＴタップ間で平均化するためにＭＲＣを実施し得る。

【0101】

本発明のいくつかの例示的な実施例による、ＵＤＰパケットを使用するビデオ送信における小さいオーバーヘッド隠蔽を実施する例示的な方法のフローチャートである図７が参照される。本方法は、より多くのステップを用いて又はより少ないステップを用いて、及び／或いは、随意に、異なる順序で配列されたステップを用いて実施され得る。

【0102】

ステップ７００において、フレーム（又はサブフレーム）に関連するＤＣＴタップは、エンコーダによってジグザグ順序で配列され得る。

【0103】

ステップ７０２において、デコーダは、量子化点．．．、－５、－３、－１、０、２、４、６、．．．の周りで量子化されたＤＣＴタップを伴う、フレーム（又はサブフレーム）の第１の記述を作成し得る。

【0104】

ステップ７０４において、デコーダは、量子化点．．．、－６、－４、－２、０、１、３、５、．．．の周りで量子化されたＤＣＴタップを伴う、フレーム（又はサブフレーム）の第２の記述を作成し得る。

【0105】

ステップ７０６において、第１の記述と第２の記述とは、各々パケット化され、別々のＵＤＰパケット中でデコーダに別々に送られ得る。

【0106】

ステップ７０８において、デコーダは、第１の記述及び第２の記述が到着したかどうかを確かめるために検査し得る。それらの記述のうちの１つのみが到着した場合、ステップ７１０に進む。両方の記述が到着した場合、ステップ７１２に進む。

【0107】

ステップ７１０において、デコーダは、小さいオーバーヘッド隠蔽を実施するために、受信された記述（第１又は第２）を使用し得る。

【0108】

ステップ７１２において、デコーダは、小さいオーバーヘッド隠蔽を実施するために、両方の受信された記述を使用し得る。たとえば、デコーダは、量子化点．．．、－２、－１、０、１、２、．．．の周りで復号し得る。

【0109】

本発明のいくつかの例示的な実施例による、ＵＤＰパケットを使用するビデオ送信における小さいオーバーヘッド隠蔽を実施する例示的な方法のフローチャートである図８が参照される。本方法は、より多くのステップを用いて又はより少ないステップを用いて、及び／或いは、随意に、異なる順序で配列されたステップを用いて実施され得る。

【0110】

ステップ８００において、フレーム（又はサブフレーム）に関連するＤＣＴタップは、エンコーダによってジグザグ順序で配列され得る。

【0111】

ステップ８０２において、デコーダは、量子化点．．．、－９、－６、－３、０、１、２、３、．．．の周りで量子化されたＤＣＴタップを伴う、フレーム（又はサブフレーム）の第１の記述を作成し得る。

【0112】

ステップ８０４において、デコーダは、量子化点．．．、－３、－２、－１、０、３、６、９、．．．の周りで量子化されたＤＣＴタップを伴う、フレーム（又はサブフレーム）の第２の記述を作成し得る。

【0113】

ステップ８０６において、第１の記述と第２の記述とは、各々パケット化され、別々のＵＤＰパケット中でデコーダに別々に送られ得る。

【0114】

ステップ８０８において、デコーダは、第１の記述及び第２の記述が到着したかどうかを確かめるために検査し得る。それらの記述のうちの１つのみが到着した場合、ステップ８１０に進む。両方の記述が到着した場合、ステップ８１２に進む。

【0115】

ステップ８１０において、デコーダは、小さいオーバーヘッド隠蔽を実施するために、受信された記述（第１又は第２）を使用し得る。

【0116】

ステップ８１２において、デコーダは、小さいオーバーヘッド隠蔽を実施するために、両方の受信された記述を使用し得る。デコーダは、たとえば、量子化点．．．、－２、－１、０、１、２、．．．の周りで復号し得る。

【0117】

本発明のいくつかの例示的な実施例による、ＵＤＰパケットを使用するビデオ送信における小さいオーバーヘッド隠蔽を実施する第４の例示的な方法のフローチャートである図９が参照される。本方法は、より多くのステップを用いて又はより少ないステップを用いて、及び／或いは、随意に、異なる順序で配列されたステップを用いて実施され得る。

【0118】

ステップ９００において、フレーム（又はサブフレーム）に関連するＤＣＴタップは、エンコーダによってジグザグ順序で配列され得る。

【0119】

ステップ９０２において、デコーダは、フレームの完全な記述であり得る、フレーム（又はサブフレーム）の第１の記述を作成し得る。

【0120】

ステップ９０４において、デコーダは、動きベクトル（ＭＶ）のみを含み得、残差のＤＣＴなしの、フレーム（又はサブフレーム）の第２の記述を作成し得る。

【0121】

ステップ９０６において、第１の記述と第２の記述とは、各々パケット化され、別々のＵＤＰパケット中でデコーダに別々に送られ得る。

【0122】

ステップ９０８において、デコーダは、第１の記述が到着したかどうかを確かめるために検査し得る。第１の記述が到着した場合、ステップ９１０に進む。第１の記述が到着しない場合、ステップ９１２に進む。

【0123】

ステップ９１０において、デコーダは、小さいオーバーヘッド隠蔽を実施するために第１の記述を使用し得る。

【0124】

ステップ９１２において、デコーダは、小さいオーバーヘッド隠蔽を実施するために第２の記述を使用し得る。デコーダは、ＭＶを使用して、及び、残差について「０」を使用して、復号し得る。

【0125】

いくつかの実施例は、ＵＤＰパケット中でビデオ・データを送信するための、及びパケット誤り隠蔽のための、方法及びシステムを含み得る。ビデオを送信する方法は、エンコーダにおいて、ビデオ・データを、単一のＩフレームと複数のＰフレームとを各々有するピクチャ・グループ（ＧＯＰ）に符号化することと、ＵＤＰパケット中でＧＯＰの各フレーム又はサブフレームを送信することとを含む。本方法は、デコーダにおいて、送信されたＵＤＰパケットのすべての受信を検査することと、すべての送信されたＵＤＰパケットの受信に応答してデコーダからエンコーダにフィードバックを送ることとを含む。誤り隠蔽の方法は、エンコーダにおいて、フレーム又はサブフレームに関連するＤＣＴタップをジグザグ順序で配列することと、ＤＣＴタップを量子化することと、量子化されたＤＣＴタップからフレーム又はサブフレームの第１の記述を作成することと、量子化されたＤＣＴタップからフレーム又はサブフレームの第２の記述を作成することと、第１の記述と第２の記述とを別々のＵＤＰパケット中でデコーダに送ることとを含む。

【0126】

いくつかの実施例では、ＵＤＰパケット中でビデオ・データを送信する方法は、エンコーダにおいて、ビデオ・データを、単一のＩフレームと複数のＰフレームとを各々含むピクチャ・グループ（ＧＯＰ）に符号化することと、ＵＤＰパケット中でＧＯＰの各フレーム又はサブフレームを送信することと、デコーダにおいて、前記送信されたＵＤＰパケットのすべての受信を検査することと、前記送信されたＵＤＰパケットのすべての受信に応答して前記デコーダから前記エンコーダにフィードバックを送ることとを含み得る。いくつかの実施例では、前記フィードバックは確認応答（ＡＣＫ）メッセージを含む。

【0127】

いくつかの実施例では、本方法は、各ＵＤＰパケット中に、（ｉ）送信されているフレーム又はサブフレームに関連するインデックス番号と、（ｉｉ）送信されるべき後続のＩフレーム又はＩサブフレームに関連するインデックス番号とを含めることをさらに含む。

【0128】

いくつかの実施例では、前記ＡＣＫメッセージは、最後の受信されたフレームに関連するインデックス番号を含む。

【0129】

いくつかの実施例では、本方法は、前記ＡＣＫメッセージを受信すると、前記エンコーダが、（Ｉ）前記後続のＩフレーム又はＩサブフレームに関連する前記インデックス番号を、（ＩＩ）前記ＡＣＫメッセージ中の前記インデックス番号に関連する新しいインデックス番号と交換することを含む。いくつかの実施例では、前記新しいインデックス番号は、前記複数のＰフレーム中のＰフレームの数を含む。いくつかの実施例では、本方法は、前記フィードバックに応答してＰフレーム又はＰサブフレームのみを送信することを含む。いくつかの実施例は、ＵＤＰビデオ送信におけるパケット誤り隠蔽の方法を含み得る。本方法は、エンコーダにおいて、フレーム又はサブフレームに関連するＤＣＴタップをジグザグ順序で配列することと、前記ＤＣＴタップを量子化することと、前記量子化されたＤＣＴタップから前記フレーム又はサブフレームの第１の記述を作成することと、前記量子化されたＤＣＴタップから前記フレーム又はサブフレームの第２の記述を作成することと、前記第１の記述と前記第２の記述とを別々のＵＤＰパケット中でデコーダに送ることとを含み得る。

【0130】

いくつかの実施例では、前記ＤＣＴタップを量子化することは、Ｑ１＜＜Ｑ２であるような２つの値Ｑ１及びＱ２を含む。いくつかの実施例では、前記第１の記述は、偶数タップについてのＱ１と、奇数タップについてのＱ２とを含む。他の実施例では、前記第１の記述は、奇数タップについてのＱ１と、偶数タップについてのＱ２とを含む。

【0131】

いくつかの実施例では、前記第１の記述中の前記ＤＣＴタップは、量子化点．．．、－５、－３、－１、０、２、４、６．．．の周りで量子化される。いくつかの実施例では、前記第２の記述中の前記ＤＣＴタップは、量子化点．．．、－６、－４、－２、０、１、３、５．．．の周りで量子化される。いくつかの実施例では、前記第１の記述中の前記ＤＣＴタップは、量子化点．．．、－９、－６、－３、０、１、２、３．．．の周りで量子化される。いくつかの実施例では、前記第２の記述中の前記ＤＣＴタップは、量子化点．．．、－３、－２、－１、０、３、６、９．．．の周りで量子化される。いくつかの実施例では、本方法は、デコーダにおいて、パケット誤り隠蔽のために前記第１の記述を使用することをさらに含む。いくつかの実施例では、本方法は、デコーダにおいて、パケット誤り隠蔽のために前記第２の記述を使用することをさらに含む。いくつかの実施例では、本方法は、デコーダにおいて、前記第１の記述中の前記量子化されたＤＣＴタップを前記第２の記述中の前記量子化されたＤＣＴタップと平均化するために、最大比合成（ＭＲＣ）を使用することをさらに含む。いくつかの実施例では、前記平均化することは加重平均化することを含む。

【0132】

いくつかの実施例では、本方法は、デコーダにおいて、前記第１の記述及び第２の記述を量子化点．．．、－２、－１、０、１、２、．．．の周りで復号することをさらに含む。

【0133】

いくつかの実施例では、本方法は、動きベクトルのみを前記第２の記述中に含めることをさらに含む。

【0134】

本発明のいくつかの追加の実施例が本明細書で説明され、それらの実施例は、随意に、前に説明された実施例の特徴及び／又は構成要素及び／又はステップと組み合わせられ得る。

【0135】

本明細書の説明の部分は、例示のために、ワイヤード・リンク及び／又はワイヤード通信に関するが、いくつかの実施例は、この点について限定されず、むしろ、ワイヤード通信及び／又はワイヤレス通信を利用し得、１つ又は複数のワイヤード及び／又はワイヤレス・リンクを含み得、ワイヤード通信及び／又はワイヤレス通信の１つ又は複数の構成要素を利用し得、並びに／或いはワイヤレス通信の１つ又は複数の方法又はプロトコル又は規格を利用し得る。

【0136】

いくつかの実施例は、一般的なコンピュータでない専用機械又は特定目的デバイスを使用することによって、或いは一般的でないコンピュータ又は非汎用コンピュータ若しくは機械を使用することによって、実装され得る。そのようなシステム又はデバイスは、「一般的なコンピュータ」の一部でない、及び「汎用コンピュータ」の一部でない、１つ又は複数の構成要素又はユニット又はモジュール、たとえば、セルラー・トランシーバ、セルラー送信機、セルラー受信機、ＧＰＳユニット、ロケーション決定ユニット、（１つ又は複数の）加速度計、（１つ又は複数の）ジャイロスコープ、デバイス配向検出器若しくはセンサー、デバイス測位検出器若しくはセンサーなどを利用し得るか、又はそれらを備え得る。

【0137】

いくつかの実施例は、自動化された方法若しくは自動化されたプロセス、又は、機械実装方法若しくはプロセスとして、又はそれらを利用することによって、実装されるか、或いは、半自動化された又は部分的に自動化された方法又はプロセスとして実装されるか、或いは、コンピュータ又は機械又はシステム又は他のデバイスによって実行又は実施され得る、ステップ又は動作のセットとして実装され得る。

【0138】

いくつかの実施例は、プロセッサ又は機械又はコンピュータによって実行されたとき、プログラム又はコード又は命令が、そのようなプロセッサ又は機械又はコンピュータに、本明細書で説明される方法又はプロセスを実施させるように、非一時的記憶媒体又は非一時的記憶物品（たとえば、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、物理メモリ・ユニット、物理記憶ユニット）に記憶され得る、コード又はプログラム・コード又は機械可読命令又は機械可読コードを使用することによって実装され得る。そのようなコード又は命令は、たとえば、（限定はしないが）高水準プログラミング言語、低水準プログラミング言語、オブジェクト指向プログラミング言語、視覚プログラミング言語、コンパイル型プログラミング言語、インタープリタ型プログラミング言語、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、ＳＱＬ、Ｒｕｂｙ ｏｎ Ｒａｉｌｓ、Ｇｏ、Ｃｏｂｏｌ、Ｆｏｒｔｒａｎ、ＡｃｔｉｏｎＳｃｒｉｐｔ、ＡＪＡＸ、ＸＭＬ、ＪＳＯＮ、Ｌｉｓｐ、Ｅｉｆｆｅｌ、Ｖｅｒｉｌｏｇ、ハードウェア記述言語（ＨＤＬ、ＢＡＳＩＣ、Ｖｉｓｕａｌ ＢＡＳＩＣ、Ｍａｔｌａｂ、Ｐａｓｃａｌ、ＨＴＭＬ、ＨＴＭＬ５、ＣＳＳ、Ｐｅｒｌ、Ｐｙｔｈｏｎ、ＰＨＰ、機械言語、機械コード、アセンブリ言語などにおけるコード又は命令を含む、ソフトウェア、ソフトウェア・モジュール、アプリケーション、プログラム、サブルーチン、命令、命令セット、コンピューティング・コード、ワード、値、シンボル、ストリング、変数、ソース・コード、コンパイル型コード、インタープリタ型コード、実行可能コード、静的コード、動的コードのうちの１つ又は複数であり得るか、或いはそれらのうちの１つ又は複数を含み得る。

【0139】

たとえば、「処理すること」、「算出すること」、「計算すること」、「決定すること」、「確立すること」、「分析すること」、「検査すること」、「検出すること」、「測定すること」などの用語を利用する本明細書の説明は、レジスタ及び／又はアキュムレータ及び／又はメモリ・ユニット及び／又は記憶ユニット内の物理（たとえば、電子）量として表されるデータを、自動的に又は自律的に他のデータに操作及び／又は変換し得るか、或いは他の好適な動作を実施し得る、プロセッサ、コンピュータ、コンピューティング・プラットフォーム、コンピューティング・システム、又は他の電子デバイス若しくはコンピューティング・デバイスの、（１つ又は複数の）動作及び／又は（１つ又は複数の）プロセスを指し得る。

【0140】

本明細書で使用される、「複数（ｐｌｕｒａｌｉｔｙ）」及び「複数（ａ ｐｌｕｒａｌｉｔｙ）」という用語は、たとえば、「複数（ｍｕｌｔｉｐｌｅ）」又は「２つ又はそれ以上」を含む。たとえば、「複数の項目（ａ ｐｌｕｒａｌｉｔｙ ｏｆ ｉｔｅｍｓ）」は、２つ又はそれ以上の項目を含む。

【0141】

「一実施例（ｏｎｅ ｅｍｂｏｄｉｍｅｎｔ）」、「一実施例（ａｎ ｅｍｂｏｄｉｍｅｎｔ）」、「例示的な実施例」、「様々な実施例」、「いくつかの実施例」、及び／又は同様の用語への言及は、そのように説明される（１つ又は複数の）実施例が、随意に、特定の特徴、構造、又は特性を含み得るが、あらゆる実施例が、必ずしも、その特定の特徴、構造、又は特性を含むとは限らないことを、指示し得る。さらに、「一実施例では」という句の繰り返される使用は、同じ実施例を指し得るが、その使用は、必ずしも、同じ実施例を指すとは限らない。同様に、「いくつかの実施例では」という句の繰り返される使用は、実施例の同じセット又はグループを指し得るが、その使用は、必ずしも、実施例の同じセット又はグループを指すとは限らない。

【0142】

別段に規定されていない限り、本明細書で使用される、項目又はオブジェクトを説明するための、「第１の」、「第２の」、「第３の」、「第４の」などの序数形容詞の利用は、そのような同様の項目又はオブジェクトの異なるインスタンスが言及されていることを指示するにすぎず、そのように説明される項目又はオブジェクトが、時間的に、空間的に、ランク付けにおいて、又は任意の他の順序付け様式においてのいずれかで、特定の所与のシーケンスにおけるものでなければならないかのように暗示するものではない。

【0143】

いくつかの実施例は、様々なデバイス及びシステム、たとえば、パーソナル・コンピュータ（ＰＣ：Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、デスクトップ・コンピュータ、モバイル・コンピュータ、ラップトップ・コンピュータ、ノートブック・コンピュータ、タブレット・コンピュータ、サーバ・コンピュータ、ハンドヘルド・コンピュータ、ハンドヘルド・デバイス、携帯情報端末（ＰＤＡ：Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）デバイス、ハンドヘルドＰＤＡデバイス、タブレット、オンボード・デバイス、オフボード・デバイス、ハイブリッド・デバイス、車両デバイス、非車両デバイス、モバイル又はポータブル・デバイス、消費者デバイス、非モバイル又は非ポータブル・デバイス、器具、ワイヤレス通信局、ワイヤレス通信デバイス、ワイヤレス・アクセス・ポイント（ＡＰ：Ａｃｃｅｓｓ Ｐｏｉｎｔ）、ワイヤード又はワイヤレス・ルータ又はゲートウェイ又はスイッチ又はハブ、ワイヤード又はワイヤレス・モデム、ビデオ・デバイス、オーディオ・デバイス、オーディオ・ビデオ（Ａ／Ｖ：ａｕｄｉｏ－ｖｉｄｅｏ）デバイス、ワイヤード又はワイヤレス・ネットワーク、ワイヤレス・エリア・ネットワーク、ワイヤレス・ビデオ・エリア・ネットワーク（ＷＶＡＮ：Ｗｉｒｅｌｅｓｓ Ｖｉｄｅｏ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ローカル・エリア・ネットワーク（ＬＡＮ：Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ワイヤレスＬＡＮ（ＷＬＡＮ：Ｗｉｒｅｌｅｓｓ ＬＡＮ）、パーソナル・エリア・ネットワーク（ＰＡＮ：Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ワイヤレスＰＡＮ（ＷＰＡＮ：Ｗｉｒｅｌｅｓｓ ＰＡＮ）などにおいて、或いはそれらとともに使用され得る。

【0144】

いくつかの実施例は、一方向及び／又は双方向無線通信システム、セルラー無線電話通信システム、モバイル・フォン、セルラー電話、ワイヤレス電話、パーソナル通信システム（ＰＣＳ：Ｐｅｒｓｏｎａｌ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）デバイス、ワイヤレス通信能力を組み込むＰＤＡ又はハンドヘルド・デバイス、モバイル又はポータブル全地球測位システム（ＧＰＳ：Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）デバイス、ＧＰＳ受信機又はトランシーバ又はチップを組み込むデバイス、ＲＦＩＤ要素又はチップを組み込むデバイス、多入力多出力（ＭＩＭＯ：Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）トランシーバ又はデバイス、単入力多出力（ＳＩＭＯ：Ｓｉｎｇｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）トランシーバ又はデバイス、多入力単出力（ＭＩＳＯ：Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｓｉｎｇｌｅ Ｏｕｔｐｕｔ）トランシーバ又はデバイス、１つ又は複数の内部アンテナ及び／又は外部アンテナを有するデバイス、デジタル・ビデオ・ブロードキャスト（ＤＶＢ：Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔ）デバイス又はシステム、多規格無線デバイス又はシステム、ワイヤード又はワイヤレス・ハンドヘルド・デバイス、たとえば、スマートフォン、ワイヤレス・アプリケーション・プロトコル（ＷＡＰ：Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）デバイスなどとともに使用され得る。

【0145】

いくつかの実施例は、無料で又は有料で、「アプリ・ストア」又は「アプリケーション・ストア」からダウンロード又は取得され得るか、或いはコンピューティング・デバイス又は電子デバイスにプリインストールされ得るか、或いは、さもなければ、そのようなコンピューティング・デバイス又は電子デバイスにトランスポート及び／又はインストールされ得る、「アプリ」又はアプリケーションを備え得るか、或いはそれらを使用することによって実装され得る。

【0146】

いくつかの実施例は、ユーザ・データグラム・プロトコル（ＵＤＰ）オーバー・インターネット・プロトコル（ＩＰ）通信リンクを介してビデオを送信する方法を含む。本方法は、ビデオ・エンコーダによって前記ビデオの各フレームごとに圧縮データのＮ個のパケットのセットを生成することであって、Ｎが自然数である、生成することと、前記ビデオの特定のフレームについてＮ個のパケットの各セットを生成すると、前記ビデオの他のビデオ・フレームの符号化又はパケット化を待つことなしに、前記ＵＤＰオーバーＩＰ通信リンクを介して、単一の符号化されたビデオ・フレームに対応するＮ個のパケットの前記セットの前記送信を直ちに実施することとを含み、前記ビデオ・フレームの各パケットは、少なくとも、（ｉ）粗いビデオ・データ・パケット部分と、（ｉｉ）細かいビデオ・データ・パケット部分とを含む。

【0147】

いくつかの実施例では、本方法は、各パケットの粗いビデオ・データ・パケット部分について、バイト単位の固定サイズ（Ｓ２）を維持することであって、サイズ（Ｓ２）が、前記単一の特定のビデオ・フレームに対応するパケットの前記セットの全体にわたって固定される、維持することと、各パケットの細かいビデオ・データ・パケット部分について、バイト単位の固定サイズ（Ｓ３）を維持することであって、サイズ（Ｓ３）が、前記単一の特定のビデオ・フレームに対応するパケットの前記セットの全体にわたって固定される、維持することとを含む。いくつかの実施例では、本方法は、前記ビデオの異なるフレームについて、利用されるＳ２の値とＳ３の値とを動的に変えることを含み、Ｓ２の前記値は、前記ビデオの各フレームのすべてのパケットにわたって固定されたままであるが、前記ビデオの少なくとも１つの他のフレームにおいてＳ２の異なる値に変わり、Ｓ３の値は、前記ビデオの各フレームのすべてのパケットにわたって固定されたままであるが、前記ビデオの少なくとも１つの他のフレームにおいてＳ３の異なる値に変わる。

【0148】

いくつかの実施例では、本方法は、特定のフレームについての細かいビデオ・データという犠牲を払って、前記特定のフレームについての増加された量の粗いビデオ・データを収容するために、粗いビデオ・データ・パケット部分のサイズを動的に増加させ、それぞれ細かいビデオ・データ・パケット部分のサイズを動的に低減することを含む。

【0149】

いくつかの実施例では、本方法は、ビデオ・フレームごとに送信されるパケットのセットにおいて、粗いビデオ・データを搬送するための粗いビデオ・データ・パケット部分の第１の数（Ｃ１）を指定することと、粗いビデオ・データを搬送する代わりに、前記粗いビデオ・データの前方誤り訂正（ＦＥＣ）コードについての冗長データを搬送するための粗いビデオ・データ・パケット部分の第２の数（Ｃ２）を指定することとを含む。

【0150】

いくつかの実施例では、本方法は、ビデオ・フレームごとに送信されるパケットのセットにおいて、細かいビデオ・データを搬送するための細かいビデオ・データ・パケット部分の第１の数（Ｆ１）を指定することと、細かいビデオ・データを搬送する代わりに、前記細かいビデオ・データの前方誤り訂正（ＦＥＣ）コードについての冗長データを搬送するための細かいビデオ・データ・パケット部分の第２の数（Ｆ２）を指定することとを含む。

【0151】

いくつかの実施例では、本方法は、Ｃ１の値と、Ｃ２の値と、Ｆ１の値と、Ｆ２の値とを選択することを含み、Ｎが、特定のビデオ・フレームについて送信されるパケットの総数であり、Ｃ１＋Ｃ２＝Ｎであり、Ｆ１＋Ｆ２＝Ｎであり、Ｆ１＞Ｃ１である。上記で使用された及び／又は本明細書で使用される「選択すること」という用語は、たとえば、定義すること、構成すること、設定すること、あらかじめ定義されたオプションのあらかじめ定義されたリストから選定すること、１つ又は複数のあらかじめ定義された選択ルールに基づいて選定すること、ビデオごとに又はフレームごとに又は他のものごとに（たとえば、１０秒又は３０秒又は６０秒など、Ｔ秒にわたるビデオ・セグメントごとに）値を定義すること、或いは、さもなければ、１つ又は複数のあらかじめ定義された基準若しくは条件に基づいて、又はあらかじめ設定された値に基づいて、（１つ又は複数の）そのような値を決定することを含み得る。

【0152】

いくつかの実施例では、本方法は、Ｎの値と、Ｃ１の値と、Ｃ２の値と、Ｆ１の値と、Ｆ２の値とを選択することを含み、Ｎは９であり、Ｃ１は５であり、Ｃ２は４であり、Ｆ１は８であり、Ｆ２は１である。

【0153】

いくつかの実施例では、本方法は、前記ビデオ・フレームの各パケットが、（ｉ）ヘッダ・パケット部分と、（ｉｉ）粗いビデオ・データ・パケット部分と、（ｉｉｉ）細かいビデオ・データ・パケット部分とを含む、を含み、本方法は、単一の特定のビデオ・フレームに対応するパケットのセット中の各パケットのヘッダ・パケット部分について、バイト単位の固定サイズ（Ｓ１）を維持することであって、サイズ（Ｓ１）が、パケットの前記セットの全体にわたって固定される、維持することと、各パケットの粗いビデオ・データ・パケット部分について、バイト単位の固定サイズ（Ｓ２）を維持することであって、サイズ（Ｓ２）が、前記単一の特定のビデオ・フレームに対応するパケットの前記セットの全体にわたって固定される、維持することと、各パケットの細かいビデオ・データ・パケット部分について、バイト単位の固定サイズ（Ｓ３）を維持することであって、サイズ（Ｓ３）が、前記単一の特定のビデオ・フレームに対応するパケットの前記セットの全体にわたって固定される、維持することとを含む。

【0154】

いくつかの実施例では、前記ビデオ・フレームの各パケットは、（ｉ）ヘッダ・パケット部分と、（ｉｉ）粗いビデオ・データ・パケット部分と、（ｉｉｉ）細かいビデオ・データ・パケット部分とを含み、本方法は、前記ビデオの異なるフレームについて、利用されるＳ１の値と、Ｓ２の値と、Ｓ３の値とを動的に変えることを含み、Ｓ１の値は、前記ビデオの各フレームのすべてのパケットにわたって固定されたままであるが、前記ビデオの少なくとも１つの他のフレームにおいてＳ１の異なる値に変わり、Ｓ２の値は、前記ビデオの各フレームのすべてのパケットにわたって固定されたままであるが、前記ビデオの少なくとも１つの他のフレームにおいてＳ２の異なる値に変わり、Ｓ３の値は、前記ビデオの各フレームのすべてのパケットにわたって固定されたままであるが、前記ビデオの少なくとも１つの他のフレームにおいてＳ３の異なる値に変わる。

【0155】

いくつかの実施例では、本方法は、ビデオ・フレームのＮ個のパケットの前記セットにおいて、ビデオ・ヘッダ・データを搬送するためのビデオ・ヘッダ・データ・パケット部分の第１の数（Ｈ１）を指定することと、ビデオ・ヘッダ・データを搬送する代わりに、前記ビデオ・ヘッダ・データの前方誤り訂正（ＦＥＣ）コードについての冗長データを搬送するためのビデオ・ヘッダ・データ・パケット部分の第２の数（Ｈ２）を指定することとを含む。

【0156】

いくつかの実施例では、本方法は、Ｎの値と、Ｈ１の値と、Ｈ２の値と、Ｃ１の値と、Ｃ２の値と、Ｆ１の値と、Ｆ２の値とを選択することを含み、Ｃ１＜Ｆ１であり、Ｈ１はＣ１よりも小さいか又はそれに等しい。

【0157】

いくつかの実施例では、本方法は、Ｎの値と、Ｈ１の値と、Ｈ２の値と、Ｃ１の値と、Ｃ２の値と、Ｆ１の値と、Ｆ２の値とを選択することを含み、Ｎは９であり、Ｈ１は３であり、Ｈ２は４であり、Ｃ１は５であり、Ｃ２は４であり、Ｆ１は８であり、Ｆ２は１である。

【0158】

いくつかの実施例では、本方法は、特定のフレームの細かいビデオ・データを搬送するために指定された細かいビデオ・データ・パケット部分の数が、前記特定のフレームについてのすべての細かいビデオ・データを搬送するには十分でない場合、細かいビデオ・データの前方誤り訂正（ＦＥＣ）コードの冗長バイトを記憶するために前に指定された少なくとも１つの細かいビデオ・データ・パケット部分に、前記特定のフレームの細かいビデオ・データを記憶することを含む。

【0159】

いくつかの実施例では、本方法は、特定のフレームの細かいビデオ・データを搬送するために指定された細かいビデオ・データ・パケット部分の数が、前記特定のフレームについてのすべての細かいビデオ・データを搬送するには十分でない場合、Ｆ１の値を動的に増加させ、それぞれＦ２の値を動的に減少させることを含む。

【0160】

いくつかの実施例では、本方法は、前記ビデオ送信を受信するように動作する受信デバイスにおいて、特定のビデオ・フレームについて受信された受信されたビデオ・ヘッダ部分中の情報に基づいて、前記特定のビデオ・フレームのパケットのセットについてＦ１の新しい値とＦ２の新しい値とを決定することを含む。

【0161】

いくつかの実施例では、本方法は、特定のフレームの粗いビデオ・データを搬送するために指定された粗いビデオ・データ・パケット部分の数が、前記特定のフレームについてのすべての粗いビデオ・データを搬送するには十分でない場合、前記特定のフレームの細かいビデオ・データを記憶するために前に指定された少なくとも１つのパケット部分に、前記特定のフレームの粗いビデオ・データを記憶することを含む。

【0162】

いくつかの実施例では、本方法は、前記ビデオ送信を受信するように動作する受信デバイスにおいて、特定のビデオ・フレームについて受信された受信されたビデオ・ヘッダ部分中の情報に基づいて、前記特定のビデオ・フレームのパケットのセットについてＣ１の新しい値とＣ２の新しい値とを決定することを含む。

【0163】

いくつかの実施例では、前記ビデオの各フレームについて生成されたパケットの各セットは、（ｉ）粗いビデオ・データを搬送するために指定されたパケット部分対（ｉｉ）粗いビデオ・データの前方誤り訂正（ＦＥＣ）コードを搬送するために指定されたパケット部分の固定比（Ｒ１）を利用し、（ｉ）細かいビデオ・データを搬送するために指定されたパケット部分対（ｉｉ）細かいビデオ・データの前方誤り訂正（ＦＥＣ）コードを搬送するために指定されたパケット部分の固定比（Ｒ２）をも利用し、（ｉ）ビデオ・ヘッダ・データを搬送するために指定されたパケット部分対（ｉｉ）ビデオ・ヘッダ・データの前方誤り訂正（ＦＥＣ）コードを搬送するために指定されたパケット部分の固定比（Ｒ３）をも利用する。

【0164】

いくつかの実施例では、前記ビデオの各フレームについて生成されたＮ個のパケットの各セットは、少なくとも、（ｉ）ビデオ・ヘッダ情報を記憶する第１の数（Ｈ１）のビデオ・ヘッダ・パケット部分と、（ｉｉ）前記ビデオ・ヘッダ・ビデオ情報の前方誤り訂正（ＦＥＣ）冗長を記憶する第２の数（Ｈ２）のビデオ・ヘッダ・パケット部分とを含み、また、あらかじめ定義されたサイズ制約が許容する場合、（Ｉ）粗いビデオ・データを記憶する第１の数（Ｃ１）の粗いビデオ・データ・パケット部分と、（ＩＩ）前記粗いビデオ・データについての前方誤り訂正（ＦＥＣ）冗長を記憶する第２の数（Ｃ２）のパケット部分とをさらに含み、また、あらかじめ定義されたサイズ制約が許容する場合、（ＩＩＩ）細かいビデオ・データを記憶する第１の数（Ｆ１）の細かいビデオ・データ・パケット部分と、（ＩＶ）前記細かいビデオ・データについての前方誤り訂正（ＦＥＣ）冗長を記憶する第２の数（Ｆ２）のパケット部分とをさらに含む。

【0165】

いくつかの実施例では、本方法は、ビデオ・フレームごとのＮ個のパケットの前記セットについてのあらかじめ定義されたバイトサイズ制約に基づいて、特定のビデオ・フレームについて、Ｎ個のパケットの前記セットから、特定のビデオ・フレームの細かいビデオ・データについての前方誤り訂正（ＦＥＣ）コードについての冗長データの少なくとも一部を除外することを動的に決定することを含む。

【0166】

いくつかの実施例では、本方法は、ビデオ・フレームごとのＮ個のパケットの前記セットについてのあらかじめ定義されたバイトサイズ制約に基づいて、特定のビデオ・フレームについて、Ｎ個のパケットの前記セットから、（ｉ）特定のビデオ・フレームの細かいビデオ・データについての前方誤り訂正（ＦＥＣ）コードについての冗長データの少なくとも一部と、（ｉｉ）前記特定のビデオ・フレームについての細かいビデオ・データの少なくとも一部とを除外することを動的に決定することを含む。

【0167】

いくつかの実施例では、本方法は、ビデオ・フレームごとのＮ個のパケットの前記セットについてのあらかじめ定義されたバイトサイズ制約に基づいて、特定のビデオ・フレームについて、Ｎ個のパケットの前記セットから、（ｉ）特定のビデオ・フレームの細かいビデオ・データについての前方誤り訂正（ＦＥＣ）コードについての冗長データの全体と、（ｉｉ）前記特定のビデオ・フレームについての細かいビデオ・データの全体とを除外することを動的に決定することを含む。

【0168】

いくつかの実施例では、本方法は、前記ビデオ送信を受信するように動作する受信デバイスにおいて、細かいビデオ・データが送信デバイスによる送信から除外された、前記特定のビデオ・フレームの１つ又は複数のサブフレームを復号することを含む。

【0169】

いくつかの実施例では、本方法は、前記ビデオ送信を受信するように動作する受信デバイスにおいて、特定のビデオ・フレームについて、完全な細かいビデオ・データでなく、部分的な細かいビデオ・データのみを受信することと、受信デバイスのＦＥＣデコーダが、前記特定のビデオ・フレームについての完全な細かいビデオ・データを再構築するのに十分な情報を有する場合、前記特定のビデオ・フレームについての完全な細かいビデオ・データを再構築することと、受信デバイスのＦＥＣデコーダが、前記特定のビデオ・フレームについての完全な細かいビデオ・データを再構築するのに十分な情報を有しない場合、前記特定のビデオ・フレームの少なくとも１つ又は複数の細かいサブフレームを再構築することとを含む。

【0170】

いくつかの実施例では、本方法は、前記ビデオの各フレームの送信を制約する、フレームごとにＮｍａｘ個のパケットの上界値を設定することを含み、Ｎｍａｘは、前記ビデオのすべてのフレームについて一様である自然数であり、前記ビデオの各フレームの圧縮ビデオ・データが、フレームごとに最高Ｎｍａｘ個のパケットを使用することによって送信される。

【0171】

いくつかの実施例では、本方法は、ビデオ・エンコーダにおいて、前記ビデオの特定のフレームについての圧縮ビデオのＫ個のパケットを生成することであって、Ｋが、前記ビデオのすべてのフレームにわたって必ずしも固定されるとは限らない自然数である、生成することと、ＫがＮｍａｘよりも小さいか又はＮｍａｘに等しい場合、前記フレームについてのすべてのＫ個のパケットを送信することと、ＫがＮｍａｘよりも大きい場合、前記フレームについての前記Ｋ個のパケットのうちの最初のＮｍａｘ個のパケットのみを送信し、前記フレームについての、最初のＮｍａｘ個のパケットを越えるパケットの送信を回避することとを含む。たとえば、ビデオ・エンコーダは、Ｋ＝１５であるように、特定のビデオ・フレームについて１５個のパケットを生成し得るが、フレームごとのパケットの最大値はＮｍａｘ＝１２であり得、したがって、その特定のフレームについてのパケットのそのセットにおいてＮ＝１２であるように、最初の１２個のパケットのみがそのフレームについて送信される。

【0172】

いくつかの実施例では、ビデオ・フレームごとのＮ個のパケットの前記セットの各パケットは、送信されたサブフレームの粗いビデオ・データと細かいビデオ・データとのマップとして利用されるビデオ・ヘッダ部分を含み、前記ビデオ・ヘッダは、前記ビデオ・フレームについての前方誤り訂正（ＦＥＣ）コードの一部又はすべてが、前記ＦＥＣコードのあまりにも少ないバイトが受信デバイスに到着したので適切に復号されなかった場合でも、前記ビデオ・フレームの１つ又は複数のサブフレームを復号するために、前記受信デバイスが、到着した細かいビデオ・データ及び／又は到着した粗いビデオ・データを少なくとも部分的に利用することを可能にする。

【0173】

本発明の１つ又は複数の実施例に関して本明細書で説明される機能、動作、構成要素及び／又は特徴は、本発明の１つ又は複数の他の実施例に関して本明細書で説明される１つ又は複数の他の機能、動作、構成要素及び／又は特徴と組み合わせられ得るか、或いはそれらと組み合わせて利用され得る。したがって、本発明は、本明細書で説明されるモジュール又は機能又は構成要素が、上記の説明の異なるロケーション又は異なるチャプターにおいて説明される場合でも、或いは、それらが、異なる図面又は複数の図面にわたって示される場合でも、それらのうちのいくつか又はすべての、任意の可能な又は好適な組合せ、再配列、アセンブリ、リアセンブリ、又は他の利用を含み得る。

【0174】

本発明のいくつかの例示的な実施例のいくつかの特徴が、本明細書で示され、説明されているが、様々な修正、置換、変更、及び等価物が当業者に想起され得る。したがって、特許請求の範囲は、すべてのそのような修正、置換、変更、及び等価物をカバーするものとする。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【国際調査報告】