JP2009027720A - 輻輳回避と共に損失パケット回復を行うシステム及び方法 - Google Patents
輻輳回避と共に損失パケット回復を行うシステム及び方法 Download PDFInfo
- Publication number
- JP2009027720A JP2009027720A JP2008189211A JP2008189211A JP2009027720A JP 2009027720 A JP2009027720 A JP 2009027720A JP 2008189211 A JP2008189211 A JP 2008189211A JP 2008189211 A JP2008189211 A JP 2008189211A JP 2009027720 A JP2009027720 A JP 2009027720A
- Authority
- JP
- Japan
- Prior art keywords
- lpr
- packet
- media
- recovery
- packets
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0009—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the channel coding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0041—Arrangements at the transmitter end
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0045—Arrangements at the receiver end
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/12—Avoiding congestion; Recovering from congestion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/38—Flow control; Congestion control by adapting coding or compression rate
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/0057—Block codes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0075—Transmission of coding parameters to receiver
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Communication Control (AREA)
Abstract
【課題】 損失パケット回復と輻輳回避とを統合することを目的とする。
【解決手段】 パケット交換ネットワークでメディア会議を行うときに、損失パケットを克服して輻輳を回避する装置及び技術が記載される。損失パケットの問題を回避するために、受信機が冗長情報から何らかの損失パケットを再構成することを可能にする冗長情報がメディアストリームに挿入される。輻輳回避技術は、メディアストリームのビットレートを調整し、輻輳によるパケット損失のないサポート可能な最高のビットレートを見つけることを含む。ビットレートを高いレートに増加させるときに、更なるビットは、損失パケットの回復に使用される冗長情報から生じ、これにより、ネットワーク輻輳により生じた何らかの損失パケットはビットストリームに悪影響を及ぼさない。
【選択図】 図11
【解決手段】 パケット交換ネットワークでメディア会議を行うときに、損失パケットを克服して輻輳を回避する装置及び技術が記載される。損失パケットの問題を回避するために、受信機が冗長情報から何らかの損失パケットを再構成することを可能にする冗長情報がメディアストリームに挿入される。輻輳回避技術は、メディアストリームのビットレートを調整し、輻輳によるパケット損失のないサポート可能な最高のビットレートを見つけることを含む。ビットレートを高いレートに増加させるときに、更なるビットは、損失パケットの回復に使用される冗長情報から生じ、これにより、ネットワーク輻輳により生じた何らかの損失パケットはビットストリームに悪影響を及ぼさない。
【選択図】 図11
Description
本発明は、輻輳回避と共に損失パケット回復を行うシステム及び方法に関する。
ますます、テレビ会議システムは、回線交換ネットワーク(PSTN及びISDN等)ではなく、パケット交換ネットワーク(インターネット等)を使用し始めてきている。テレビ会議にパケット交換ネットワークを使用することでの1つの問題は、全てのパケット交換ネットワークが或る程度のパケット損失を受けるという点にある。控えめなパケット損失であっても、ビデオ品質はかなり損なわれる。
パケット損失の問題に対する既存の対策は、様々な誤り隠蔽技術と画像リフレッシュ機構とを使用することを含む。有用ではあるが、これらの技術はしばしば不十分である。これらは、頻繁に特定のビデオコーデックと統合されており、これらの技術がコーデック技術の進展毎に改革されることを必要とする。
典型的には、パケット交換ネットワークは、少なくとも2つの基本的な種類のパケット損失を有する。ネットワークのレイヤ1及び2が回復されない情報を損失したときに、物理的損失が生じ得る。例えば無線リンク(例えば、802.11a、802.11b、802.11g及び802.11nのようなWiFiネットワーク)が使用されるときに、この種類の損失は一般的である。しかし、有線及び光ファイバリンクでも物理レイヤの損失が生じ得る。第2の種類のパケット損失は、ネットワーク輻輳から生じ得る。
この第2の種類のパケット損失を克服するために、或るテレビ会議装置は、様々な輻輳回避技術を使用している。1つのこのような技術は、2002年11月26日に出願された“System and Method for Dynamic Bandwidth Allocation for Videoconferencing in Lossy Packet Switched Systems”という題の米国特許出願10/305,485号に記載されている。この特許出願の全ての内容を援用する。このような技術は、“動的帯域割り当て(Dynamic Bandwidth Allocation)”又は“DBA”と呼ばれることがある。これらの種類のDBAアルゴリズムは、帯域を増加使用とすると常にパケット損失を取り込むという本質的なリスクがある。このことは、損なわれた媒体という結果になり得る。他の種類の輻輳回避技術は、VCONのPacketAsssistと、損失パケット回復又は輻輳制御に関する他の標準とを含む。例えば、RFC2733は、XOR(パリティ)パケットを使用する損失パケット回復方法を提供する。RFC3448は、RFC4340と同様に、ユニキャスト輻輳制御方法を提供する。
更に、前方消失訂正(forward erasure correction)及び前方誤り訂正(forward error correction)のような損失データ回復技術が、ネットワークのレイヤ1及び2で使用され得る。これらの技術もまた、RAIDディスク及びCDROM/DVDのような記憶媒体で使用されている。近年、3GPPは前方誤り訂正を標準化した。前方誤り訂正はまた、H.320を介して送信されるビデオストリームにも提供され得る。
米国特許出願10/305,485号
RFC2733
RFC3448
これまで、(例えば前方消失訂正を使用した)損失パケット回復と輻輳回避とを統合する実現は行われていない。このような統合を含むアルゴリズムを記載する。
一態様では、本発明は、損失のあるネットワークを通じて送信されたメディアストリームの破損を回避する方法に関する。この方法は、損失パケット回復アルゴリズムをメディアストリームに適用することを含み得る。損失パケット回復アルゴリズムは、メディアストリームを含む送信データストリームに冗長情報を挿入することにより動作し得る。冗長情報は、前方消失訂正及び/又はリードソロモン符号化を使用して生成され得る。この方法は、輻輳回避アルゴリズムを送信データストリームに適用することを更に含み得る。輻輳回避アルゴリズムは、送信データストリームのデータレートを一時的に増加させ、ネットワークが高いデータレートをサポートすることができるか否かを決定することを更に含み得る。データレートは、送信データストリームに挿入される冗長情報の量を増加させることにより、一時的に増加し得る。
本発明はまた、損失のあるネットワークで受信したメディアデータを回復する方法に関し得る。メディアストリームは、データストリームと冗長情報とを有するデータストリームの一部として送信されている。この回復方法は、メディアストリームと冗長情報とを有する複数のパケットを受信し、受信パケットからメディアストリームの損失部分を再構成することを含み得る。
本発明はまた、前述のデータ回復及び輻輳回避を実行するように適合されたテレビ会議装置に関し得る。
本発明の実施例によれば、パケット損失を低減することが可能になる。
前方消失訂正と輻輳回避との使用を組み合わせたネットワーク送信で、損失パケットの影響を克服する技術が開示される。これらの技術は、“損失パケット回復(Lost Packet Recovery)”又は“LPR”と呼ばれることがある。
LPRは、損失RTPメディアパケットを回復するスケーラブルな方法である。ここに記載する例はビデオコーデックを対象としているが、メディアに特有ではない。ここに記載するLPR技術はまた、他の種類のRTPメディアストリームを保護するために使用され得る。LPRは、損失メディアパケットの前方消失訂正を提供するために、リードソロモン符号化を使用し、損失メディアパケットの回復を可能にする。
LPRが使用される場合、RTPペイロードは、ほぼ等しいサイズのデータパケットを生成するように再パケット化される。再パケット化されたストリームは、異なるRTPダイナミックペイロード形式(これは割り当てられたメディアペイロード番号と異なる)を使用し、完全にRTPに準拠する。ペイロード特有のヘッダは、元のRTPパケットを再構成するのに十分な情報を含む。LPRは、SSRC及びCSRC情報が回復セット(以下に説明する)の途中で変化しないことを仮定する。タイムスタンプ、シーケンス番号、元のペイロード形式及びマーカ・ビット(marker bit)が完全に回復され、回復されたRTPストリームが復号化可能になることを確保する。
次に、回復パケットは、このRTPストリームに追加される。回復パケットもRTPに準拠する。各回復パケットはまた、保護されたデータパケットを記述するペイロードヘッダを含む。各パケットのRTPペイロードは回復情報を含む。追加された回復パケットの数は、RTCP受信レポートから推定されたチャネル損失率に依存する。約50%のビットレートのオーバーヘッドを有するが、約15%までのチャネル損失率に対応可能である。
LPR保護は、全体メディアのビットレートの一部と考えられない点に留意すべきである。従って、実際に圧縮されたペイロードのみが数えられる。しかし、ネットワーク輻輳を回避するために、総計ビットレートが必要に応じて低減され得る。ネットワーク輻輳は、パケット損失以外に又はパケット損失に加えて望ましくない影響を有し得る点に留意すべきである。例えば、ネットワーク輻輳は、媒体の待ち時間の増加と、接続(シグナリング接続を含む)の劣化を生じ得る。従って、LPRプロトコルは、輻輳回避のための内蔵メッセージを有し得る。1つの適切な輻輳回避アルゴリズムについて以下に詳細に説明するが、様々な輻輳回避アルゴリズムが使用されてもよい。
メディアストリームに適用されるLPRの例について、図1〜3を参照して説明する。ビットレート、パケット損失率、パケットサイズ、データパケット対回復パケットの比等を含むこの例の詳細は、全てが単なる例であり、実装の詳細、チャネル状態等に応じて変化し得る。
2%のパケット損失率を有する300kbpsのビデオチャネルについて検討する。3つのパケット101、102及び103が送信される。(6+2)のLPRモードが使用される。これは、2つの回復パケット104、105が6つのデータパケット106〜111の各グループに挿入され、それぞれ8パケットの回復セットを生成することを意味する。回復パケット104、105は、最大データパケットとほぼ同じサイズであるが、何らかの更なるオーバーヘッドを含む。以下に詳細に説明するように、回復パケットは、6つのデータパケット106〜111のいずれか2つの再生成を可能にする。
300kbpsのチャネル制限内に留まるために、メディアレートは、約220kbpsまで低減可能であり、回復パケットに80kbpsを残す。それぞれの再パケット化されたデータパケットの目標サイズは500バイトになり得る。従って、各回復セットは、約32000ビットの情報を伝達し、これは、300kbpsのチャネルレートで107msの期間を表す。107msの期間は、保護期間と呼ばれる。
各パケット(すなわち、再パケット化されたデータパケット106〜111及び回復パケット104、105)は、通常の40バイトのIP+UDP+RTPヘッダのオーバーヘッドを含む。簡単にするために、このオーバーヘッドは示されていない。しかし、LPR自体に関連するオーバーヘッドが示されている。例えば、“3+420”は、420バイトの元のデータに加えて3バイトのオーバーヘッドがパケットに存在することを示す。回復パケットは100%のオーバーヘッドになる。オーバーヘッドの詳細は、以下に詳細に説明する。
図2は、回復処理を示している。データパケット3及び5(108、111)が損失したことを仮定する。LPRデコーダは、受信した6つのパケット(すなわち、データパケット1、2、4及び6並びに回復パケット1及び2)から再生成パケット201及び202を生成する。損失パケットの再生成は、6つのパケットが受信されるまで生じることができない点に留意すべきである。再生成の後に、元のRTPパケット203〜205がデータパケットから復元される。損失パケットの再生成は、以下に詳細に説明する。
図3は、2つより多くのパケットが損失したときのパケット回復の失敗を示している。この例では、データパケット3及び5と同様に、回復パケット1が損失している。グループのうち5つのみのパケットが受信されたため、パケット再生成は不可能である。LPRデコーダは部分的なパケットを再生成しない。元のパケットが完全に回復できない場合、部分的なパケット情報は破棄される。従って、データパケット1及び2(301、302)の双方が損失したものとして示されている。
図3に示すように、元のデータパケットの全てが回復できない場合、受信側デコーダが全体画像の高速更新を要求することが一般的である。代替として、2006年3月28日に発行された“Dynamic Intra-coded Macroblock Refresh Interval for Video Error Concealment”という題の米国特許7,020,203号に記載のようなウォークアラウンド・リフレッシュ(walk-around refresh)を要求する。この米国特許の全ての内容を援用する。いずれの場合でも、画像を訂正するために必要な時間は、損失したパケットの数の関数ではなく、回復セットの所定数のパケット(この例では2つ)より多くを損失することによりもたらされた失敗の間の平均時間になる。
300kbps及び2%のパケット損失のチャネルで、6つのデータパケットと2つの回復データパケットとの各保護セットが107msのチャネルデータをカバーする所定の例では、失敗の間の平均時間は、約258秒であると計算され得る。高速更新が約2秒を要求することを仮定すると、所与のLPRの例により保護されるチャネルで送信されるビデオは、99%より多くの時間で誤りのないことになる。この保護は、80kbpsの更なるオーバーヘッドをもたらし、これは約30%のチャネルレートになる。
前述のLPRの例の更なる態様は、図4を参照してより良く理解され得る。図4は、LPRエンコーダの実装を示している。この実装の変形も可能である。ビデオエンコーダ401は、ほとんど通常の方法で動作する様々なビデオエンコーダのいずれかでもよい。例えば、ビデオエンコーダは、H.261、H.263、H.264、MPEG-2、又はMPEG-4ビデオ圧縮標準に従って動作し得る。代替として、ビデオエンコーダは、様々な独自仕様のビデオコーディング技術のいずれかに従って動作し得る。
ビデオエンコーダ401の出力は、任意選択の暗号化モジュール402に供給され得る。暗号化モジュール402もまた、様々な既知の種類のいずれかでもよい。暗号化されたビデオデータ(又は暗号化が使用されない場合には暗号化されていないビデオデータ)は、RTP送信機403に供給され得る。RTP送信機403も通常のものでもよい。RTP送信機403により生成されたRTPパケットは、以下に詳細に説明するように、LPRパケット化器406によりLPRアルゴリズムを使用して再パケット化され得る。LPR回復パケット生成器407は、以下に詳細に説明するように、LPRパケット化器406及びビデオエンコーダ401から受信した情報に基づいて回復パケットを生成し得る。LPR回復パケット生成器は、LPRデータパケットとLPR回復パケットとを受信機(図示せず)に送信し得る。
RTCPモジュール404は、パケット損失及び他のチャネル統計を受信し、これらをLPRモード判定モジュール405に供給し得る。LPRモード判定モジュール405はLPRパケット化器406を制御する。LPRモード判定モジュール405は、LPR保護を行うか行わないかを判定し、使用されるLPR保護パラメータを決定し得る。LPR保護が行われない場合、LPRパケット化器406及びLPR回復パケット生成器407は、RTP送信機403により生成されたRTPパケットを、変更せずに通過し得る。
LPRモード判定モジュール405は以下のように動作し得る。まず、(前述の)保護期間が決定され得る。長い保護期間は効率的なパケット再生成(例えば少ない回復kbps)を提供するが、長い待ち時間を生成する。最も典型的なテレビ会議のビットレートでは、100msが適切な保護期間になり得る。128kbpsより小さいビットレートでは、長い保護期間が必要になってもよい。例えば、150msが64kbpsのレートに適する可能性がある。1Mbpsより大きいビットレートでは、短い保護期間が有利なことがある。例えば、50msが2Mbps以上のレートに適する可能性がある。他のパラメータも保護期間を決定する際に検討され得る。
次に、保護期間毎の全パケット数が決定され得る。一般的に、保護期間毎に小さいパケット数は、保護の効率を減少させる傾向になり得る。逆に、保護期間毎に大きいパケット数は、保護パケットをエンコード及びデコードするために必要な計算量を増加させる傾向になり得る。従って、ほとんどのチャネルについて、保護期間毎に約13以上のパケットが適切であると考えられる。保護期間毎のパケット数についての判定は、所望のデータレートに対する結果のパケットサイズも考慮すべきである。出力パケットサイズ(IPオーバーヘッドを含む)は、分割せずにIPSECトンネルを横断するために、1260バイト未満であるべきである。
保護期間毎のパケット数が定められると、保護期間毎の回復パケット数が選択され得る。回復パケット数は、(通常の確率的分析技術を使用して)保護の中断の間の平均時間が所定の規定値を満たす又は超えるように選択され得る。更に、全ての送信されたビデオチャネルの総計(LPR保護パケット及びRTPメッセージを含む)が、指定の輻輳上限を超えないように選択され得る。
以下のテーブルは、様々な損失条件で様々なビットレートに使用され得る例示的な保護モデルを示している。テーブル1は、パケット損失が3%を超えるときにデータレートを低減する輻輳回避アルゴリズム(以下に説明する)と共に使用可能であり、4%のパケット損失条件に適し得るLPRパラメータを示している。テーブル2は、輻輳回避アルゴリズムが使用中でないときに使用され得る2%のパケット損失条件のLPRパラメータを示している。
[表1]
[表2]
LPRパケット化器406は以下のように動作し得る。LPRパケット化器406は、パケット再生成符号化の効率を改善するために、RTP送信機403により生成された元のメディアパケットを細分する。LPRデータパケットは、唯一の発信元パケットからの情報を含む。メディアチャネルが暗号化されている場合、暗号化ストリームでLPR再パケット化が実行され得る。一般的に、LPRストリーム自体は再暗号化されない。すなわち、暗号化パケットと新しく生成されたLPR回復パケットとに追加されたLPRカプセル化フィールド(ヘッダ)は、平文で送信される。
[表1]
[表2]
LPRパケット化器406は以下のように動作し得る。LPRパケット化器406は、パケット再生成符号化の効率を改善するために、RTP送信機403により生成された元のメディアパケットを細分する。LPRデータパケットは、唯一の発信元パケットからの情報を含む。メディアチャネルが暗号化されている場合、暗号化ストリームでLPR再パケット化が実行され得る。一般的に、LPRストリーム自体は再暗号化されない。すなわち、暗号化パケットと新しく生成されたLPR回復パケットとに追加されたLPRカプセル化フィールド(ヘッダ)は、平文で送信される。
元の発信元パケットが細分される場合(例えば、図1〜3のパケット1 101)、この発信元パケットの最初のLPRデータパケットは初期データパケット(例えば、図1〜3のデータ1 106)と呼ばれる。(存在する場合には)次のデータパケットは、後続データパケット(例えば、図1〜3のデータ2 107及びデータ3 108)と呼ばれる。後続データパケットの数は、初期データパケットで伝達され、従って、初期データパケットが送信されると変更できない。後続データパケット及び初期データパケットは、異なるLPR保護グループに存在してもよい。
シーケンス番号とペイロード形式とPフィールドとを除いて、元のRTPヘッダの全てのフィールドは、各LPRデータパケットで変更されずに伝達され得る。これは、タイムスタンプとマーカ・ビットとSSRC/CSRC情報とを含む。ペイロード番号は、ネゴシエーションされたLPRペイロード形式と交換され得る。シーケンス番号は、通常通りにLPRメディアストリームに連続的に割り当てられ得る。LPRパケットのPフィールドは0に設定され得る。LPRパケット化器406は、元のRTPシーケンス番号をLPR回復パケット生成器407に渡し得る。
各初期データパケットは、LPRに特有の7バイトのペイロードヘッダを含み得る。この例が図5に示されている。各後続データパケットは、3バイトのペイロードヘッダを含み得る。この例が図6に示されている。これらのペイロードヘッダは、RTPヘッダの直後に続き、ビデオ(又は他のメディア)ペイロードに先行し得る。ヘッダサイズ及び個々のフィールドのサイズ並びにこれらの構成は単なる例であり、他の構成も可能であることがわかる。
回復パケットのフィールド501、601は、回復セットで後に送信される回復パケット数を示すために使用され得る。回復セットの全てのデータパケットは、同じ数の回復パケットを伝達するべきである。伝達される回復パケット数は0でもよく、これは回復パケットが送信されないことを示す。このフィールドは6ビットのフィールドでもよく、64の回復パケットまでを許容する。形式のフィールド502、602は、それぞれ初期データパケット又は後続データパケットを示すために、00又は01に設定される2ビットのフィールドセットでもよい。これは、最初のペイロードバイトを検査することにより、LPRのヘッダ形式が決定されることを可能にする。
データインデックスのフィールド503、603は8ビットのフィールドでもよい。回復セットの最初のデータパケットは1のデータインデックスを割り当てられ得る。データインデックスは、そのセットの次のデータパケットでインクリメントされ得る。後続パケットのフィールド504は、初期パケットに関連する後続パケット数を指定するために使用される8ビットのフィールドでもよい。データパケットのフィールド604は、回復セットに含まれるデータパケット数を伝達するために使用される8ビットのフィールドでもよい。全てのデータパケットは、同じ数のデータパケットを伝達するべきである。
元のシーケンスのフィールド505は、元のRTPパケットシーケンス番号を示す16ビットのフィールドでもよい。これは、元のRTPパケットを再生成するために使用される。元のPビットのフィールド506は、元のRTPパケットにより伝達されるパディングビット(padding bit)を伝達するために使用される1ビットのフィールドでもよい。元のペイロード形式のフィールド507は、元のRTPパケットにより伝達されるペイロード形式を伝達するために使用される7ビットのフィールドでもよい。
LPR回復パケット生成器407は、以下のように動作し得る。LPR回復パケット生成器407は、元のメディアのRTPシーケンス番号を、LPRデータパケットの最後のLPRシーケンス番号と交換し得る。LPR回復パケット生成器407はまた、各回復セットの終わりにLPR回復パケットを挿入し得る。
各回復パケットはまた、図7に示すような9バイトのヘッダを含み得る。回復パケットヘッダは、RTPヘッダの直後に続き、ビデオ(又は他のメディア)ペイロードに先行し得る。前述のヘッダと同様に、フィールドの形式及びサイズは例示的であり、他の構成も使用されてもよい。
回復インデックスのフィールド701は、回復セットの回復パケットのシーケンスを示すために使用される6ビットのフィールドでもよい。最初の回復パケットは、1の回復インデックスを割り当てられ得る。回復インデックスは、回復セットの次の回復パケットでインクリメントされ得る。形式のフィールド702は、パケットが回復パケットであることを示すために、10に設定される2ビットのフィールドでもよい。回復パケットのフィールドは、回復セットのデータパケット数を含む8ビットのフィールドでもよい。全ての回復パケットは、対応するデータパケットにより伝達された同じ数の回復パケットを伝達するべきである。データパケットのフィールド704は、回復セットで送信されるデータパケット数を示す8ビットのフィールドでもよい。回復パケットは、対応するデータパケットで示された同じ数のデータパケットを示すべきである。
保護タイムスタンプのフィールド705は、回復セットの各データパケットのリードソロモン符号化されたRTPタイムスタンプを保持する32ビットのフィールドでもよい。これは、回復ペイロード自体で使用されるものと同じリードソロモン符号化を使用して結合され得る。このフィールドにより、損失データパケットのRTPタイムスタンプが再生成されることが可能になる。4バイトはネットワークの指示(in network order)である。
保護マーカ、フラグ及びサイズのフィールド706(図8に更に示す)は、リードソロモン符号化されたRTPマーカ・ビット802、フラグ値801及びデータパケットサイズ803を保有し得る。フラグ値は、LPRデータパケットが初期パケットである場合に1になってもよく、LPRデータパケットが後続パケットである場合に0に設定されてもよい。サイズは、LPRヘッダと同様にIP、UDP及びRTPヘッダを含み得る。データパケットサイズはネットワークの指示でもよい。
保護フィールドは、回復ペイロード自体で使用されたものと同じリードソロモン符号化を使用して結合される。このフィールドにより、回復可能な何らかの損失データパケットについて、LPRヘッダ形式、マーカ及びデータパケットサイズが再生成されることが可能になる。
回復パケットのペイロードは、リードソロモン256(RS256)符号化を使用して符号化され得る。初期データパケットの元のシーケンス505、元のPビット506、元のペイロード形式507及び後続パケット504のフィールドは、ペイロードバイトであるかのように保護され得る。これにより、初期データパケットが損失した場合に、この情報が回復可能になる。更に、回復パケットのペイロードヘッダは、3つのファントムデータ(Phantom Data)のフィールド(データパケット自体の長さ、マーカ・ビット及びタイムスタンプ)の符号化を含み得る。この場合も同様に、これにより、細分されたRTPパケットの全てのデータパケットが損失した場合に、この情報が回復可能になる。
各データパケットの各ペイロードバイトは、以下のRS256の生成関数に従って、各回復パケットの対応するバイトに寄与し得る。
[表3]
ガロア域(28)算術演算は、2つの補助テーブル(ガロア・ログ関数(glog)テーブル及びガロア指数関数(gexp)テーブル)を使用して設定され得る。これらのテーブルは以下の通りである。
[表4]
[表5]
これらのテーブルは、以下に説明する様々な算術演算を計算するために使用され得る。
ガロア域(28)の加算及び減算は同じ演算であり、以下のように実行される。
a÷b=gexp[glog[a]-glog[b]+255]
ただし、+は通常の加算演算であり、-は通常の減算演算である。通常の演算と同様に、a÷1=aである。また、通常通り、bは0ではない。
ガロア域(28)のべき乗関数(ab)は以下のように実行される。
ab=gexp[(glog[a]*b)%0xFF]
ただし、+は通常の加算演算であり、-は通常の減算演算であり、*は通常の乗算演算であり、%は通常のmod関数である。通常の演算と同様に、0でないaについてa0=1である。RS256参照コードでは、0は決してべき乗にならない。
ab=gexp[(glog[a]*b)%0xFF]
ただし、+は通常の加算演算であり、-は通常の減算演算であり、*は通常の乗算演算であり、%は通常のmod関数である。通常の演算と同様に、0でないaについてa0=1である。RS256参照コードでは、0は決してべき乗にならない。
前述のように、(パケットの)LPRグループサイズは、所望の保護期間(ミリ秒)を実現するように設定され得る。ビデオコーデックが全チャネルビットレートを使用しない場合、LPRグループは長い待ち時間を生じる。例えば、通常では1.5Mbpsで動作するビデオチャネルは、軽い動作期間に(in periods of light motion)750kbpsに低下し得る。これは、所望の2倍の長さの保護期間を生じる。このような状況は、選択されたLPRモードが所定のMTBFを満たし続けることを生じ得る。この例では、2の係数だけ所定のMTBFを超える。
或る場合には、この拡張保護期間が許容され得る。しかし、パケットが損失した場合に、これは長い待ち時間を生じ得る。従って、或る場合には、実際のビデオレートが変化するときに、送信機がそのLPRモードを調整することが望ましいことがある。3つのこのような調整について以下に説明するが、他の調整も可能である。
行うことができる1つの調整は、保護グループサイズに対するものである。或る実施例では、この設定は、各保護グループの境界で変更され得る。従って、送信機は、LPR出力パケットレートを監視し、グループ毎のパケット数を動的に適合させ得る。この調整が使用される場合、データレートが下がると、LPR保護オーバーヘッドは上がる傾向になる。しかし、このような場合のデータレートは一般的に通常の制限より小さいため、変更されたLPRモードは、一般的に依然として所定の輻輳上限の下に留まる。
行うことができる他の調整は、送信機が初期データパケットの送信時にその出力パケットサイズを変更することである。典型的には後続パケット数が初期データパケットで伝達されているため、一般的に、送信機は、後続パケットを送信するときに出力パケットサイズを変更するべきでない。従って、送信機は、LPR出力パケットレートと出力データレートとを監視し、保護期間毎のパケット数を維持するようにパケットサイズを動的に適合させ得る。
行うことができる他の調整は、送信機が空のデータパケットを送信して部分的な回復セットを完了することである。空のデータパケットは、前述の初期データパケットヘッダを含み得る。パケットに通常存在する他の情報(シーケンス番号、ペイロード形式、後続パケット数等)は、全て0に設定され得る。空のデータパケットは保護グループの一部であるため、前述の回復パケットの符号化はこれらのパケットを含み得る。これらのパケットはまた、デコード処理により回復可能である。また、空のデータパケットは、出力メディアパケットストリームの空のパケットを回避するために、LPRデコーダ(以下に説明する)により破棄され得る。
詰め込まれたパケット(fill packet)は、所定のデータレートを維持するために使用され得る。これらの詰め込まれたパケットは、受信機により破棄され得る。例示的な詰め込まれたパケットが図9に示されている。詰め込まれたパケットは、1の値を有する6ビットの拡張形式のフィールド901と、11の値を有する2ビットの形式のフィールド902とを含み得る。詰め込まれたパケットは、メディアストリームのLPRペイロード形式を使用したRTPパケットでもよい。タイムスタンプの値は、前に送信されたRTPパケットの値と同じでもよい。シーケンス番号は、前に送信されたパケットの値からインクリメントされてもよい。ペイロードは、前述の詰め込まれたヘッダで終了し得る。フィールドのペイロード長は、最大の指定パケットサイズ内で如何なる長さでもよい。
LPRデコーダの例が図10に示されている。前述のLPRエンコーダと同様に、この実施例の変形も可能である。LPRデコーダの動作は、基本的に前述のLPRエンコーダの逆になり得る。具体的には、LPRパケットは、LPR回復モジュール1001により回復され得る。これらの回復されたLPRパケットは、RTP並び替えバッファ1002に渡され、RTP並び替えバッファは、通常のシステムと同様に、パケットを受信順に並び替え得る。LPR再生成器1003は、(LPR回復ブロック1001から)回復されたLPRパケットから受信した情報と、RTPCモジュール1006から受信したRTCP情報とに基づいて、何らかの損失パケットを再生成し得る。これらの再生成されたブロックは、(暗号化が発信元で使用されている場合)復号化ブロック1004により復号化され得る。最後に、復号化されたブロックがビデオデコーダ1005(又は必要に応じて他の種類のメディアエンコーダ)により処理され得る。
LPR回復モジュール1001及びLPR再生成器1003のみは、通常のシステムと比べて非標準の要素でもよく、これらの2つのモジュールはLPRが使用されないときにパススルー(pass-through)として動作し得る。
LPR回復モジュール1001は、全てのLPR RTPパケットを処理し得る。所与の例では、受信して再生成された全てのパケット(データ及び回復)は、直接にRTP並び替えバッファに渡され得る。各データパケットのオーバーヘッドデータにより、これらのパケットが何らかの順序でLPR回復モジュール1001により処理されることが可能になる。LPR回復モジュール1001はまた、LPR RTP受信レポート情報をRTCPモジュール1006に提供し得る。この情報は、何が受信されたかに基づいてもよい(例えば、受信されていない何らかのパケットが受信レポートで損失として特定され得る)。
回復可能な回復セットに損失データパケットが存在する場合、十分な回復パケットが受信されるとすぐに、LPR回復モジュールはこれらのパケットを回復し得る。前述のように、kのデータパケットが損失している場合、データを回復するためにkの回復パケットが受信されなければならない。この回復処理は、まず、マーカ・ビットと、データパケット長と、初期パケットフラグと、元のタイムスタンプとを回復することを含み得る。データパケット長は、元のデータパケットのペイロードを回復するために使用され得る。LPR RTPヘッダの“固定”の構成要素(例えば、SSRC、CSRC、LPRペイロード形式等)は、1つの回復パケットから採用され得る。LPR RTPヘッダの様々な部分(例えば、マーカ・ビット、タイムスタンプ及びシーケンス番号)は、回復ヘッダから回復された値に設定され得る。
LPRデータパケットiのシーケンス番号は以下の式に従って計算され得る。
Si=Sr-(d+r-i)
ただし、iは回復データパケットのインデックスであり、dは回復セットのデータパケット数であり、rは受信した回復パケットのインデックスであり、Siはパケットiのシーケンス番号である。
Si=Sr-(d+r-i)
ただし、iは回復データパケットのインデックスであり、dは回復セットのデータパケット数であり、rは受信した回復パケットのインデックスであり、Siはパケットiのシーケンス番号である。
データパケットを受信する間に、前述のRS256生成関数を使用して、部分的な回復パケットが回復モジュール1001により構築され得る。そのセットの対応する回復パケットが受信されると、これらのパケットは、部分的な回復パケットと排他的論理和(XOR)され得る。結果の残りのパケットは、各回復パケットへの何らかの損失データパケットの寄与を保持する。例示的なシステムでは、それぞれの残りのパケットは、損失データパケットのそれぞれの線形結合である。従って、kの連立方程式(kの残りのパケットのそれぞれに1つ)が存在し、それぞれkの未知数(損失したkのデータパケットのそれぞれに1つ)が存在する。
当業者にわかるように、これらの式はk×kの行列として表され得る。k×kの行列は、例えばガウス消去法により数学的に解決され得る。このような演算は周知であるため、詳細はここでは説明しない。残りのデータで結果の逆行列を乗算することにより、損失データパケットを回復することができる。
前述の回復処理を示すために、図2の回復シナリオが実行され得る。明瞭にするために、実際のガロア域(28)の演算ではなく、通常の算術演算が使用される。回復パケットのデータは、以下の式(前述のRS256生成関数及びテーブルから導かれる)を使用して生成され得る。
R1=D1+D2+D3+D4+D5+D6
R2=2D1+4D2+6D3+9D4+13D5+14D6
部分的な回復パケットは、受信したパケットでデコーダにより計算され得る。前述の例で記載したように、パケット3及び4(図3の108、110)は受信されない。その結果、以下のようになる。
P1=D1+D2+D5+D6
P2=2D1+4D2+13D5+14D6
残りは、受信した回復パケットから部分的な回復パケットを減算することにより計算され得る。
r1=R1-P1=D3+D4
r2=R2-P2=6D3+9D4
従って、残りの生成行列は以下のようになる。
R1=D1+D2+D3+D4+D5+D6
R2=2D1+4D2+6D3+9D4+13D5+14D6
部分的な回復パケットは、受信したパケットでデコーダにより計算され得る。前述の例で記載したように、パケット3及び4(図3の108、110)は受信されない。その結果、以下のようになる。
P1=D1+D2+D5+D6
P2=2D1+4D2+13D5+14D6
残りは、受信した回復パケットから部分的な回復パケットを減算することにより計算され得る。
r1=R1-P1=D3+D4
r2=R2-P2=6D3+9D4
従って、残りの生成行列は以下のようになる。
D3=3r1-r2/3
D4=-2r1+r2/3
LPRが使用中である場合、RTP並び替えバッファ1002はLPRデコーダと統合され得る。或る状況では、パケットが実際に到達する前に順序の狂ったパケットがLPRにより再生成され得るため、これは最小遅延の実装を可能にする。更に、或る実施例では、何らかのデータパケットが損失した場合にのみリードソロモンデコーダを動作して、回復セットの最初のdのパケットを取得することが望ましいことがある。この設計は最小の遅延を生じないことがあるが、計算効率が良くなり得る。
LPR再生成モジュール1003は、前述のように、データパケットから元のRTPストリームを再生成し得る。RTPパケットの何らかのデータパケットが損失している場合、そのRTPパケットは出力ストリームから省略される。LPRストリームは並び替えられているため、各パケットからの初期パケットが最初に受信されるべきである。後続パケットが最初に直面する場合、初期パケットが損失しており、後続パケットが破棄され得る。
出力RTPパケットは、初期データパケットのRTPヘッダ情報を使用する。ペイロード形式、シーケンス番号及びタイムスタンプは、初期データヘッダの値と交換される。ペイロードは、LPRヘッダが取り除かれて、初期データパケットと何らかの後続データパケットとから集められる。何らかの後続パケットが損失している場合、出力RTPパケットが抑制され得る。後続パケット数は初期データパケットのヘッダで伝達され得るため、既知でもよい点に留意すべきである。
前述のような損失パケット回復技術は、更に動作を拡張するために、輻輳回避アルゴリズムと結合され得る。例示的な輻輳回避アルゴリズムは前述の通りであり、動的帯域割り当て(DBA:Dynamic Bandwidth Allocation)と呼ばれる。DBAは、受信機のRTPスタック(図10の1006)により報告されたパケット損失率に基づいてビットレートを下げることにより、輻輳を回避しようとし得る。受信機のRTPスタックは、一定の期間中(例えば毎200ms)の受信機のチャネルのパケット損失統計を生成する。これは、低いMTBF要件を有する最小のLPR構成を可能にしつつ、動的に変化するパイプへの高速な適合を可能にする(次に、これは低いオーバーヘッドを可能にする)。
図11に示すように、DBAの制御ループは、最大レート状態1101と、速度低下状態1102と、速度上昇待機状態1103と、速度上昇状態1104と、常時損失状態1105とを有する状態機械として実現され得る。様々な状態遷移は以下のようになることがわかる。システムが最大レート状態1101(最大データレートが使用されていることを意味する)であることを仮定する。所定の閾値より大きいパケット損失は、速度低下状態1102への状態遷移1106を生じ得る。
速度低下状態において、システムは速度を減少させ、所定の閾値より大きいパケット損失を受け続けるか否かを検出するために待機する。閾値より大きいパケット損失が存在しない場合、システムは、速度上昇待機状態への遷移1108に従い得る。閾値より大きいパケット損失が存在し続け、最大数の速度低下の試行が使用されていない場合(ブロック1107)、システムは速度低下状態1102を続け、従って、ビットレートを減少させ続け得る。最大数の速度低下の試行が使用された場合、システムは常時損失状態1105に遷移する。
速度上昇待機状態において、所定の閾値より大きい更なるパケット損失は、システムを速度低下状態への遷移1109に従わせ得る。代替として、所定の期間の後に閾値より大きいパケット損失が存在しない場合、システムは、速度上昇状態1104への遷移1110に従い得る。
速度上昇状態1104において、システムは、ビットレートを増加させ、所定の閾値より大きい更なるパケット損失を待機し得る。パケット損失が存在しない場合、システムは、ビットレートが最大ビットレートより小さいか否かを決定し得る。小さい場合、システムは最大レート状態1101への遷移1111に従い得る。小さくない場合、システムは速度上昇状態1104を続け得る。速度上昇状態1104の間に所定の閾値より大きいパケット損失を受ける場合、システムは、所定の最大数の速度上昇の試行が行われたか否かを決定し得る(ブロック1112)。最大数の速度上昇の試行が行われていない場合、システムは、速度上昇待機状態への遷移1113に従い得る。最大数の速度上昇の試みが使用されている場合、システムは最大レート状態1101への遷移1114に従い得る。
前述の状態のそれぞれにおいて、異なるパケット損失閾値が使用されてもよい。更に、状態遷移の一部又は全てが、これらに関連する遅延を有してもよい。速度上昇は、ビットレートの15%ステップの増加で行われてもよい。パイプが完全に利用されており、パケット損失が報告されていない場合、次の速度上昇が生じる前にXタイマ周期(200ms*X)に等しくなり得る遅延がもたらされ得る。初期設定でXの値は2に設定され、400msの遅延を生じてもよい。連続的なパケット損失のレポートではなく、エコーレポートではない何らかのパケット損失は、状態遷移を生じ得る。
図12は、動的に変化する帯域の可用性とDBA適合とを示している。図12はまた、3つの一般的な損失のシナリオ(バースト損失、抑制されたパイプ及び常時損失)と共に、状態遷移、エコー遅延を示している。LPR保護の使用は、速度低下状態、速度上昇待機状態及び速度上昇状態の間の図12の斜線の領域で示されている。速度上昇の試行は、輻輳上限をテストするために、LPR保護のオーバーヘッドを使用し得る。すなわち、ネットワーク輻輳状態が高いビットレートを許容するか否かを調べるために“冗長”データのみが使用されてもよい。輻輳上限のテストが失敗すると、“冗長”データのみが使用されているため、LPRはもたらされたパケット損失により生じた何らかの損失を保護する。このことにより、ビデオの中断のリスクを実質的に低減して、輻輳上限の調査が可能になる。
測定された輻輳上限は、完全にデータフローに適用可能である。例えば、複数のビデオストリームが送信されている場合、輻輳上限は総計ビットレートに適用し得る。前方消失保護は各ビデオストリームに独立して適用可能である。しかし、同じレベルの保護が全てのストリームに適用され得る。システムはまた、共通の前方消失訂正パケットでビデオストリームを併せて保護するように適合されてもよく、各ビデオストリームに異なるレベルの保護を適用するように適合されてもよい。
前方消失訂正はまた、ビデオストリームの一部のみに適用され得る。例えば、階層化ビデオ符号化が使用される場合、前方消失保護は、基本レイヤに適用されて、拡張レイヤに適用されなくてもよい。これはまた、様々なレイヤを異なる程度に保護するように適合されてもよい(いわゆる“不平等な保護(unequal protection)”)。これらの構成では、輻輳回避は全体データフローに当てはまる。
輻輳上限測定の例示的なLPRの調査(probe)がテーブル6に示されている。これらの調査は、所定値(例えば10%)だけデータレートを上昇させる可能性をテストするために使用され、短い期間(例えば800ms)の間に動作し得る。
[表6]
ここに記載された技術は、受信機が輻輳上限と消失保護レベルとを送信機にフィードバックという点で受信機主導でもよい。代替として、これらは、送信機主導のフレームワーク、又は制御ループが送信機と受信機との間で分散されるハイブリッド型フレームワークで使用され得る。何らかの適合で、マルチキャストストリームでの使用にも適する。記載された技術はまた、パケット再送信、周期的画像リフレッシュ及びビデオ誤り隠蔽のような他の技術と結合され得る。
[表6]
ここに記載された技術は、受信機が輻輳上限と消失保護レベルとを送信機にフィードバックという点で受信機主導でもよい。代替として、これらは、送信機主導のフレームワーク、又は制御ループが送信機と受信機との間で分散されるハイブリッド型フレームワークで使用され得る。何らかの適合で、マルチキャストストリームでの使用にも適する。記載された技術はまた、パケット再送信、周期的画像リフレッシュ及びビデオ誤り隠蔽のような他の技術と結合され得る。
前述のように、輻輳回避と前方消失訂正との組み合わせは、何れかの機構がそれ自体で実現できない固有の利点を提供する。1つのこのような利点は、ビットストリームでの前方消失保護パケットの量を実験的に増加させ、配信されたデータフローでの影響を観測することにより、輻輳上限が周期的に測定され得るという点にある。これらの保護パケットは、パケット損失からメディアを保護するのと同時に(レベルが輻輳上限を超える場合)、全体データレートを所望の“調査”レベルに増加させる。第2の利点は、輻輳上限を動的に測定するこの方法は、輻輳回避アルゴリズムで通常に使用されている受動的な方法により提供されるものより、許容帯域の非常に高速な決定を生じ得るという点にある。第3の利点は、全体フロー(メディア及び保護)が動的に測定された輻輳上限の下に留まるように抑制されたときに、保護されたメデイアフローが少ない遅延及び小さい保護オーバーヘッドで配信され得るという点にある。
ここに記載された技術の更なる利点は、ビデオデータレートが増加したときに、システムがパケット損失に対して保護するのに効率的になり得るという点にある。従って、高解像度ビデオの使用等でビットレートが増加すると、ここに記載された技術は、有用且つ効率的になる。
前方消失訂正と輻輳回避との統合は、複数の固有の利点を提供する。例えば、輻輳回避は、前方消失訂正に対して複数の固有の利点をもたらす。データリンクが混雑すると、そのリンクを通じた媒体の送信遅延が増加する。前方消失訂正のみを使用することは、許容可能なパケット損失率を生じ得るが、待ち行列遅延を低減しない。輻輳回避を制御ループに統合することにより、非常に小さい待ち時間で所望のサービス品質(QoS)を実現できる。更に、前方消失保護の効率は、大きい待ち時間のアプリケーションより小さい待ち時間のアプリケーションで小さくなる。データ損失の原因が簡単な輻輳である場合、ビットレートを低減することは、データフローに更なる前方消失訂正パケットを増加することより効率的になり得る。
逆に、前方消失訂正はまた、輻輳回避のみのものにかなりの価値を追加し得る。典型的には、輻輳回避技術は、データフローのレートを積極的に低減する。例えば、TCPの輻輳機構は、乗算係数だけデータレートを低減するが、加算係数を適用することにより非常に低く上がる。この理由は、データフローレートを増加することは、常に輻輳を生じるリスクがあり、従ってパケット損失を生成するからである。前方消失訂正が輻輳回避と統合されると、このリスクはかなり低減される。従って、前述のように、前方消失保護パケットの密度を単に増加させることにより、データレートが増加し得る。
更に、輻輳回避技術はまた、リンク速度を推定するように設計される。他のデータフローからの相互輻輳(cross-congestion)は、頻繁にパケット損失を生じ得る。相互輻輳が観測される時間までに、通常ではパケット損失は既に生じている。前方消失保護を含めることにより、このような相互輻輳によるパケット損失が回復可能になる。
ここに開示された技術は、マルチメディアデータ(ビデオデータ、オーディオデータ、静止画データ及び他の種類のデータ等)の送信用の何らかのシステムを含み、様々なシステムで使用され得る。このような技術は、典型的な汎用コンピュータシステム(デスクトップコンピュータ、ノートブックコンピュータ、ハンドヘルドコンピュータ、サーバ等)で使用され得る。代替として、これらの技術は、様々な装置形式のシステム(会議部屋のテレビ会議システム、デスクトップ型テレビ会議システム等)で使用され得る。ここに記載された技術はまた、インフラストラクチャ形式のテレビ会議装置(マルチポイント制御ユニット(MCU:multi-point control unit)、ブリッジ、メディアサーバ等)で使用され得る。
ここに記載された方法は、1つ以上のコンピュータプログラムにコード化され、コンピュータ可読媒体(コンパクトディスク、テープ、揮発性又は不揮発性メモリ等)に格納され得る。従って、プログラム記憶装置に格納された命令は、ここに記載された技術をプログラム可能制御装置(例えば、コンピュータ又は会議ユニット)に実行させるために使用され得る。開示された通信システムは、近端(near end)及び遠端(far end)の間の双方向通信を提供するものとして記載されているが、この開示の教示は一方向送信を提供するシステムにも適用可能であることがわかる。
好ましい実施例及び他の実施例の前述の説明は、出願人により考案された本発明の概念の範囲又は適用性を制限又は限定することを意図しない。ここに含まれる本発明の概念を開示する代わりに、出願人は特許請求の範囲により提供される全ての特許権を望む。従って、特許請求の範囲は、請求項又はその均等の範囲内にある全ての内容に対する全ての変更及び変形を含むことを意図する。
Claims (21)
- 損失のあるネットワークを通じて送信されたメディアストリームの破損を回避する方法であって、
損失パケット回復アルゴリズムを前記メディアストリームに適用し、前記損失パケット回復アルゴリズムは、前記メディアストリームを含む送信データストリームに冗長情報を挿入し、1つ以上の損失パケットの再構成を可能にし、
輻輳回避アルゴリズムを前記送信データストリームに適用し、前記輻輳回避アルゴリズムは、前記送信データストリームに挿入された冗長情報の量を増加させることにより、前記送信データストリームのデータレートを一時的に増加させ、前記ネットワークが高いデータレートをサポートすることができるか否かを決定することを含む
ことを有する方法。 - 前記冗長情報は、1つ以上の回復パケットを有する、請求項1に記載の方法。
- 回復パケット数は、RTCP受信レポートから決定されたチャネル損失率に依存する、請求項2に記載の方法。
- ネットワーク輻輳を回避するために必要に応じて総計ビットレートを低減することを更に有する、請求項1に記載の方法。
- 前記損失パケット回復アルゴリズムは、前方消失訂正符号化を含む、請求項1に記載の方法。
- 前記損失パケット回復アルゴリズムは、リードソロモン符号化を含む、請求項1に記載の方法。
- 前記メディアストリームは、ビデオデータを有する、請求項1に記載の方法。
- ネットワークでメディアデータを送信するメディア符号化装置であって、
メディアエンコーダと、
前記メディアエンコーダからの出力を受信し、リアルタイム送信プロトコルに従って前記メディアエンコーダの出力を複数の発信元パケットとしてパッケージ化するように接続されたRTP送信機と、
前記ネットワークからチャネル情報を受信するように接続されたRTCPモジュールと、
前記RTCPモジュールから前記チャネル情報を受信するように通信可能に結合され、前記チャネル情報から使用されるLPR保護パラメータを決定するように適合され、前記LPR保護パラメータをLPRパケット化器に提供するように通信可能に結合されたLPRモード判定モジュールと、
RTP送信機からの出力を受信し、前記LPRモード判定モジュールから受信したパラメータを使用して前記RTP送信機の出力を複数のLPRデータパケットとして再パケット化するように接続されたLPRパケット化器と、
前記LPRパケット化器及び前記メディアエンコーダに結合され、前記LPRパケット化器及び前記メディアエンコーダから受信した情報に基づいてLPR回復パケットを生成するように適合され、前記LPRデータパケットと前記LPR回復パケットとを受信機に送信するように適合されたLPR回復パケット生成器と
を有するメディア符号化装置。 - 前記メディアエンコーダはビデオエンコーダである、請求項8に記載のメディア符号化装置。
- 前記LPRモード判定モジュールは、
保護期間を決定し、
保護期間毎の合計パケット数を決定し、
保護期間毎の回復パケット数を決定する
ことによりLPR保護パラメータを決定する、請求項8に記載のメディア符号化装置。 - 各LPRデータパケットは、唯一の発信元パケットからの情報を含む、請求項8に記載のメディア符号化装置。
- 前記回復パケットのペイロードは、リードソロモン符号化を使用して符号化される、請求項8に記載のメディア符号化装置。
- パケット型ネットワークで行われるメディア会議のLPR保護パラメータを決定する方法であって、
保護期間を決定し、
保護期間毎の合計パケット数を決定し、
保護期間毎の回復パケット数を決定する
ことを有する方法。 - 前記保護期間は、前記メディア会議のビットレートに従って決定される、請求項13に記載の方法。
- メディアレートの関数としてLPR保護パラメータを調整することを更に有する、請求項3に記載の方法。
- 前記メディアレートの関数としてLPR保護パラメータを調整することは、グループ毎のパケット数を動的に適合させることを有する、請求項15に記載の方法。
- 前記メディアレートの関数としてLPR保護パラメータを調整することは、パケットサイズを動的に適合させることを有する、請求項15に記載の方法。
- 前記メディアレートの関数としてLPR保護パラメータを調整することは、空のデータパケットを送信することを有する、請求項15に記載の方法。
- ネットワークで送信機からメディアデータを受信するメディア復号化装置であって、
前記ネットワークから、LPRデータパケットとLPR回復パケットとを含むLPRパケットを受信するように結合されたLPR回復モジュールと、
前記LPRデータパケットを受信し、何らかの損失データパケットを再生成するように適合されたLPR再生成器と、
前記LPR再生成器に通信可能に結合され、前記LPR再生成器から損失パケットのレポートを受信し、損失パケット情報を前記送信機に送信するRTCPモジュールと、
前記LPR再生成器に結合され、前記LPRデータパケットと前記再生成されたデータパケットとを受信し、含まれるメディア情報をデコードするように結合されたメディアデコーダと
を有するメディア復号化装置。 - 前記メディアデコーダはビデオデコーダである、請求項19に記載のメディア復号化装置。
- 前記LPR回復モジュール及び前記LPR再生成器は、LPRアルゴリズムが使用中でないときにパススルーとして動作する、請求項19に記載のメディア復号化装置。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US95139907P | 2007-07-23 | 2007-07-23 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012170941A Division JP5661693B2 (ja) | 2007-07-23 | 2012-08-01 | 輻輳回避と共に損失パケット回復を行うシステム及び方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2009027720A true JP2009027720A (ja) | 2009-02-05 |
Family
ID=39930524
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008189211A Pending JP2009027720A (ja) | 2007-07-23 | 2008-07-22 | 輻輳回避と共に損失パケット回復を行うシステム及び方法 |
JP2012170941A Expired - Fee Related JP5661693B2 (ja) | 2007-07-23 | 2012-08-01 | 輻輳回避と共に損失パケット回復を行うシステム及び方法 |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012170941A Expired - Fee Related JP5661693B2 (ja) | 2007-07-23 | 2012-08-01 | 輻輳回避と共に損失パケット回復を行うシステム及び方法 |
Country Status (4)
Country | Link |
---|---|
US (2) | US7876685B2 (ja) |
EP (1) | EP2019522B1 (ja) |
JP (2) | JP2009027720A (ja) |
CN (1) | CN101364946B (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2016092686A1 (ja) * | 2014-12-12 | 2016-06-16 | 株式会社日立製作所 | 通信装置、通信装置システム及び通信方法 |
WO2021238940A1 (zh) * | 2020-05-26 | 2021-12-02 | 维沃移动通信有限公司 | 视频数据处理方法、装置和电子设备 |
Families Citing this family (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8990663B2 (en) * | 2006-12-21 | 2015-03-24 | Thomson Licensing | Method to support forward error correction for real-time audio and video data over internet protocol networks |
JP5094593B2 (ja) * | 2008-06-27 | 2012-12-12 | キヤノン株式会社 | 送信装置、受信装置、及び方法、プログラム |
US8995356B2 (en) | 2009-10-14 | 2015-03-31 | Qualcomm Incorporated | Coding methods and apparatus for broadcast channels |
US8386266B2 (en) | 2010-07-01 | 2013-02-26 | Polycom, Inc. | Full-band scalable audio codec |
US8831932B2 (en) | 2010-07-01 | 2014-09-09 | Polycom, Inc. | Scalable audio in a multi-point environment |
CN102761530A (zh) * | 2011-04-29 | 2012-10-31 | 华为终端有限公司 | 媒体码流传输方法、装置及系统 |
KR101930057B1 (ko) | 2011-10-28 | 2018-12-17 | 한국전자통신연구원 | 통신 시스템에서 데이터 송수신 장치 및 방법 |
CN103152545B (zh) * | 2011-12-07 | 2016-02-10 | Polycom通讯技术(北京)有限公司 | 一种处理纠错请求的方法、视频服务器和视频会议系统 |
US8819513B2 (en) | 2012-01-13 | 2014-08-26 | Microsoft Corporation | Lost real-time media packet recovery |
US20130182705A1 (en) * | 2012-01-18 | 2013-07-18 | Uri AVNI | Method and system for transmitting encoded video signals |
KR20130126876A (ko) | 2012-04-30 | 2013-11-21 | 삼성전자주식회사 | 통신 시스템에서 패킷 송수신 방법 및 장치 |
US8904024B2 (en) * | 2012-08-03 | 2014-12-02 | Ittiam Systems (P) Ltd | System and method for low delay fast update for video streaming |
US9270792B2 (en) * | 2012-11-21 | 2016-02-23 | Ubiquiti Networks, Inc. | Method and system for improving wireless link efficiency |
CN104348577B (zh) * | 2013-08-01 | 2019-01-08 | 波利康公司 | 用于编码多媒体数据的设备和方法 |
GB2555755A (en) * | 2014-06-20 | 2018-05-09 | Starleaf Ltd | A telecommuincation end-point device data transmission controller |
GB2527365B (en) * | 2014-06-20 | 2018-09-12 | Starleaf Ltd | A telecommunication end-point device data transmission controller |
US10154317B2 (en) | 2016-07-05 | 2018-12-11 | BoxCast, LLC | System, method, and protocol for transmission of video and audio data |
US10763903B2 (en) | 2016-08-25 | 2020-09-01 | Nec Corporation | Wireless communication apparatus, method, and storage medium having program stored therein |
US10594661B1 (en) * | 2017-06-13 | 2020-03-17 | Parallels International Gmbh | System and method for recovery of data packets transmitted over an unreliable network |
TWI717808B (zh) * | 2019-08-16 | 2021-02-01 | 圓展科技股份有限公司 | 多媒體資料傳輸方法及多媒體資料傳輸裝置 |
NO20211386A1 (en) | 2021-11-18 | 2022-08-08 | Pexip AS | Method, system and computer program product for initiating downspeeding in a videoconferencing session |
NO346978B1 (en) * | 2021-11-26 | 2023-03-20 | Pexip AS | Method, system and computer program product for upspeeding in a videoconferencing session |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002281078A (ja) * | 2001-03-21 | 2002-09-27 | Ntt Docomo Inc | 通信品質制御方法、通信品質制御システム、パケット解析装置及びデータ送信端末装置 |
JP2004289621A (ja) * | 2003-03-24 | 2004-10-14 | Fujitsu Ltd | データ伝送サーバ |
JP2005151600A (ja) * | 2000-10-31 | 2005-06-09 | Toshiba Corp | データ伝送装置、データ伝送方法及びプログラム |
JP2005175837A (ja) * | 2003-12-10 | 2005-06-30 | Sony Corp | 送信装置および方法、受信装置および方法、記録媒体、並びにプログラム |
JP2006345523A (ja) * | 2005-06-10 | 2006-12-21 | Samsung Electronics Co Ltd | 誤り訂正パケットを用いた伝送率制御方法およびそれを用いた通信装置 |
Family Cites Families (73)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4894823A (en) * | 1986-02-28 | 1990-01-16 | American Telephone And Telegraph Company | Time stamping for packet system nodes |
US5146477A (en) * | 1987-03-17 | 1992-09-08 | Antonio Cantoni | Jitter control in digital communication links |
US4935816A (en) | 1989-06-23 | 1990-06-19 | Robert A. Faber | Method and apparatus for video image film simulation |
US5821984A (en) | 1992-09-09 | 1998-10-13 | Canon Kabushiki Kaisha | Communication conference system with storage of conference information including proceedings data |
JPH07162830A (ja) | 1993-12-10 | 1995-06-23 | Ricoh Co Ltd | テレビ会議通信装置の制御方法 |
JPH08149130A (ja) | 1994-11-25 | 1996-06-07 | Canon Inc | 映像コミュニケーションシステム |
US5838664A (en) | 1997-07-17 | 1998-11-17 | Videoserver, Inc. | Video teleconferencing system with digital transcoding |
KR0163723B1 (ko) | 1995-03-20 | 1999-01-15 | 김광호 | 종합정보통신망을 이용한 화상회의시스템의 화상회의 제어장치 |
DE19524808A1 (de) | 1995-07-07 | 1997-01-09 | Thomson Brandt Gmbh | Verfahren, Encoder und Decoder zur Resynchronisierung auf einen fehlerbehafteten Datenstrom |
US5768263A (en) | 1995-10-20 | 1998-06-16 | Vtel Corporation | Method for talk/listen determination and multipoint conferencing system using such method |
US5889945A (en) | 1995-12-27 | 1999-03-30 | Intel Corporation | System for dynamically updating information in panels within an attendee bar corresponding to a conference session when selected information regarding to conferencing participants changes |
US6122259A (en) | 1996-02-27 | 2000-09-19 | Hitachi, Ltd. | Video conference equipment and multipoint video conference system using the same |
US5953049A (en) | 1996-08-02 | 1999-09-14 | Lucent Technologies Inc. | Adaptive audio delay control for multimedia conferencing |
US6215821B1 (en) * | 1996-08-07 | 2001-04-10 | Lucent Technologies, Inc. | Communication system using an intersource coding technique |
US5917830A (en) | 1996-10-18 | 1999-06-29 | General Instrument Corporation | Splicing compressed packetized digital video streams |
JP3434653B2 (ja) | 1996-12-05 | 2003-08-11 | 富士通株式会社 | マルチメディアデータ蓄積伝送方法及び装置 |
US5844615A (en) | 1997-01-16 | 1998-12-01 | General Instrument Corporation | Communication of VBI data in digital television data streams |
US5886734A (en) | 1997-01-28 | 1999-03-23 | Videoserver, Inc. | Apparatus and method for storage and playback of video images and audio messages in multipoint videoconferencing |
US6141448A (en) | 1997-04-21 | 2000-10-31 | Hewlett-Packard | Low-complexity error-resilient coder using a block-based standard |
US6680976B1 (en) | 1997-07-28 | 2004-01-20 | The Board Of Trustees Of The University Of Illinois | Robust, reliable compression and packetization scheme for transmitting video |
WO1999005602A1 (en) | 1997-07-28 | 1999-02-04 | Zhigang Chen | A robust, reliable compression and packetization scheme for transmitting video |
US6006253A (en) | 1997-10-31 | 1999-12-21 | Intel Corporation | Method and apparatus to provide a backchannel for receiver terminals in a loosely-coupled conference |
US6104757A (en) | 1998-05-15 | 2000-08-15 | North Carolina State University | System and method of error control for interactive low-bit rate video transmission |
US6421387B1 (en) | 1998-05-15 | 2002-07-16 | North Carolina State University | Methods and systems for forward error correction based loss recovery for interactive video transmission |
US6078328A (en) | 1998-06-08 | 2000-06-20 | Digital Video Express, Lp | Compressed video graphics system and methodology |
US6646987B1 (en) * | 1998-10-05 | 2003-11-11 | Nortel Networks Limited | Method and system for transmission control protocol (TCP) packet loss recovery over a wireless link |
US6025870A (en) | 1998-10-14 | 2000-02-15 | Vtel Corporation | Automatic switching of videoconference focus |
US6317462B1 (en) | 1998-10-22 | 2001-11-13 | Lucent Technologies Inc. | Method and apparatus for transmitting MPEG video over the internet |
US6629318B1 (en) | 1998-11-18 | 2003-09-30 | Koninklijke Philips Electronics N.V. | Decoder buffer for streaming video receiver and method of operation |
US6771674B1 (en) * | 1998-12-28 | 2004-08-03 | 3Com Corporation | Method and system for forward error correction based on parallel streams |
US7423983B1 (en) * | 1999-09-20 | 2008-09-09 | Broadcom Corporation | Voice and data exchange over a packet based network |
US6263371B1 (en) | 1999-06-10 | 2001-07-17 | Cacheflow, Inc. | Method and apparatus for seaming of streaming content |
US6208620B1 (en) * | 1999-08-02 | 2001-03-27 | Nortel Networks Corporation | TCP-aware agent sublayer (TAS) for robust TCP over wireless |
US7606164B2 (en) | 1999-12-14 | 2009-10-20 | Texas Instruments Incorporated | Process of increasing source rate on acceptable side of threshold |
US6611530B1 (en) | 1999-09-21 | 2003-08-26 | Hewlett-Packard Development Company, L.P. | Video communication using multiple streams |
US6728924B1 (en) | 1999-10-21 | 2004-04-27 | Lucent Technologies Inc. | Packet loss control method for real-time multimedia communications |
JP2001119376A (ja) * | 1999-10-21 | 2001-04-27 | Nec Corp | 回線エラー監視方式 |
WO2001031858A2 (de) * | 1999-10-28 | 2001-05-03 | Siemens Aktiengesellschaft | Verfahren zum verbessern der datenübertragungsqualität in datenpaketorientierten kommunikationsnetzen |
US7133407B2 (en) | 2000-01-25 | 2006-11-07 | Fujitsu Limited | Data communications system |
JP3478223B2 (ja) * | 2000-02-10 | 2003-12-15 | 日本電気株式会社 | スタッフィング制御回路 |
JP3841256B2 (ja) * | 2000-02-15 | 2006-11-01 | 三菱電機株式会社 | 通信システム及び通信方法及び送信端末 |
US7539130B2 (en) * | 2000-03-28 | 2009-05-26 | Nokia Corporation | Method and system for transmitting and receiving packets |
US6920149B2 (en) * | 2000-05-30 | 2005-07-19 | Lucent Technologies Inc. | Digital data transmission system |
US6757248B1 (en) * | 2000-06-14 | 2004-06-29 | Nokia Internet Communications Inc. | Performance enhancement of transmission control protocol (TCP) for wireless network applications |
US7657913B2 (en) * | 2000-06-14 | 2010-02-02 | Sony Corporation | Method and apparatus for correcting corrupted digital video transport streams |
WO2002035847A2 (en) | 2000-10-27 | 2002-05-02 | Polycom Israel Ltd. | Apparatus and method for improving the quality of video communication over a packet-based network |
US7103669B2 (en) | 2001-02-16 | 2006-09-05 | Hewlett-Packard Development Company, L.P. | Video communication method and system employing multiple state encoding and path diversity |
EP1246383A1 (en) * | 2001-03-28 | 2002-10-02 | Lucent Technologies Inc. | Data transmission system |
US7099273B2 (en) * | 2001-04-12 | 2006-08-29 | Bytemobile, Inc. | Data transport acceleration and management within a network communication system |
US7103047B1 (en) * | 2001-06-26 | 2006-09-05 | Juniper Networks, Inc. | Method and apparatus for modifying the rate of MPEG transport streams |
US6757735B2 (en) | 2001-07-03 | 2004-06-29 | Hewlett-Packard Development Company, L.P. | Method for distributing multiple description streams on servers in fixed and mobile streaming media systems |
KR20030095995A (ko) * | 2002-06-14 | 2003-12-24 | 마츠시타 덴끼 산교 가부시키가이샤 | 미디어 전송방법 및 그 송신장치 및 수신장치 |
JP3734774B2 (ja) * | 2002-06-21 | 2006-01-11 | 株式会社リコー | ネットワークファクシミリ装置、及び、ファクシミリ通信方法 |
US7656905B2 (en) * | 2002-12-24 | 2010-02-02 | Samir Sheth | Apparatus and method for aggregation and transportation of gigabit ethernet and other packet based data formats |
US7295549B2 (en) * | 2003-02-14 | 2007-11-13 | Ntt Docomo, Inc. | Source and channel rate adaptation for VoIP |
US7974195B2 (en) * | 2003-06-12 | 2011-07-05 | California Institute Of Technology | Method and apparatus for network congestion control |
US20050013249A1 (en) * | 2003-07-14 | 2005-01-20 | Hao-Song Kong | Redundant packets for streaming video protection |
JP4328602B2 (ja) * | 2003-11-20 | 2009-09-09 | 富士通株式会社 | パケットエラー訂正装置及び方法 |
JP2005252622A (ja) * | 2004-03-03 | 2005-09-15 | Kitakyushu Foundation For The Advancement Of Industry Science & Technology | 通信装置及び通信方法 |
US7660245B1 (en) * | 2004-09-16 | 2010-02-09 | Qualcomm Incorporated | FEC architecture for streaming services including symbol-based operations and packet tagging |
JP4459794B2 (ja) * | 2004-11-30 | 2010-04-28 | 日本電信電話株式会社 | 符号誤り訂正を行うデータ送信方法、受信方法、装置、システム及びプログラム |
WO2006060036A1 (en) * | 2004-12-02 | 2006-06-08 | Thomson Licensing | Adaptive forward error correction |
KR101236080B1 (ko) * | 2005-05-06 | 2013-02-21 | 캘리포니아 인스티튜트 오브 테크놀로지 | 손실된 패킷 검출 방법 및 패킷에 대한 재전송 메카니즘을결정하는 방법 |
JP4580278B2 (ja) * | 2005-05-20 | 2010-11-10 | 財団法人エヌエイチケイエンジニアリングサービス | パケット中継装置、コンテンツ送信装置、パケット中継プログラムならびにパケット中継方法 |
KR100843073B1 (ko) | 2005-06-10 | 2008-07-03 | 삼성전자주식회사 | 오류 정정 패킷을 이용한 전송률 제어 방법 및 이를 이용한통신 장치 |
KR20080068745A (ko) * | 2005-12-15 | 2008-07-23 | 미쓰비시덴키 가부시키가이샤 | 통신 시스템, 송신측 통신 장치 및 수신측 통신 장치 |
US8089892B2 (en) * | 2005-12-15 | 2012-01-03 | Thomson Licensing | Adaptive joint source and channel coding scheme for H.264 video multicasting over wireless networks |
US20070147249A1 (en) * | 2005-12-22 | 2007-06-28 | Brijesh Kumar | Cross layer optimization for improving TCP performance in lossy wireless environments |
KR100900438B1 (ko) * | 2006-04-25 | 2009-06-01 | 삼성전자주식회사 | 음성 패킷 복구 장치 및 방법 |
US7957307B2 (en) * | 2007-03-14 | 2011-06-07 | Microsoft Corporation | Reducing effects of packet loss in video transmissions |
US20080285476A1 (en) * | 2007-05-17 | 2008-11-20 | Yasantha Nirmal Rajakarunanayake | Method and System for Implementing a Forward Error Correction (FEC) Code for IP Networks for Recovering Packets Lost in Transit |
US7839859B2 (en) * | 2007-12-03 | 2010-11-23 | Nec Laboratories America, Inc. | Voice adaptive gateway pacing methods and systems for wireless multi-hop networks |
US8775658B2 (en) * | 2009-03-27 | 2014-07-08 | Wyse Technology L.L.C. | Apparatus and method for transparent communication architecture in remote communication |
-
2008
- 2008-07-22 JP JP2008189211A patent/JP2009027720A/ja active Pending
- 2008-07-22 EP EP08013179.0A patent/EP2019522B1/en active Active
- 2008-07-23 US US12/178,367 patent/US7876685B2/en active Active
- 2008-07-23 CN CN2008101686766A patent/CN101364946B/zh active Active
-
2010
- 2010-12-14 US US12/967,787 patent/US8493862B2/en active Active
-
2012
- 2012-08-01 JP JP2012170941A patent/JP5661693B2/ja not_active Expired - Fee Related
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005151600A (ja) * | 2000-10-31 | 2005-06-09 | Toshiba Corp | データ伝送装置、データ伝送方法及びプログラム |
JP2002281078A (ja) * | 2001-03-21 | 2002-09-27 | Ntt Docomo Inc | 通信品質制御方法、通信品質制御システム、パケット解析装置及びデータ送信端末装置 |
JP2004289621A (ja) * | 2003-03-24 | 2004-10-14 | Fujitsu Ltd | データ伝送サーバ |
JP2005175837A (ja) * | 2003-12-10 | 2005-06-30 | Sony Corp | 送信装置および方法、受信装置および方法、記録媒体、並びにプログラム |
JP2006345523A (ja) * | 2005-06-10 | 2006-12-21 | Samsung Electronics Co Ltd | 誤り訂正パケットを用いた伝送率制御方法およびそれを用いた通信装置 |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2016092686A1 (ja) * | 2014-12-12 | 2016-06-16 | 株式会社日立製作所 | 通信装置、通信装置システム及び通信方法 |
JPWO2016092686A1 (ja) * | 2014-12-12 | 2017-07-27 | 株式会社日立製作所 | 通信装置、通信装置システム及び通信方法 |
US10104016B2 (en) | 2014-12-12 | 2018-10-16 | Hitachi, Ltd. | Communication device, communication device system, and communication method |
WO2021238940A1 (zh) * | 2020-05-26 | 2021-12-02 | 维沃移动通信有限公司 | 视频数据处理方法、装置和电子设备 |
Also Published As
Publication number | Publication date |
---|---|
US20110096776A1 (en) | 2011-04-28 |
US20090046580A1 (en) | 2009-02-19 |
JP2012235523A (ja) | 2012-11-29 |
US7876685B2 (en) | 2011-01-25 |
EP2019522B1 (en) | 2018-08-15 |
JP5661693B2 (ja) | 2015-01-28 |
CN101364946B (zh) | 2013-08-14 |
EP2019522A3 (en) | 2009-07-22 |
EP2019522A2 (en) | 2009-01-28 |
CN101364946A (zh) | 2009-02-11 |
US8493862B2 (en) | 2013-07-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5661693B2 (ja) | 輻輳回避と共に損失パケット回復を行うシステム及び方法 | |
US7539187B2 (en) | System and method for low-latency content-sensitive forward error correction | |
JP6893237B2 (ja) | データストリーミングの前方誤り訂正 | |
Li | RTP payload format for generic forward error correction | |
TWI364988B (en) | Error filter to differentiate between reverse link and forward link video data errors | |
JP4405875B2 (ja) | エラー訂正用データの生成方法及び生成装置並びに生成プログラム及び同プログラムを格納したコンピュータ読み取り可能な記録媒体 | |
JP4475235B2 (ja) | コンテンツの符号化、配信及び受信方法と装置とシステムならびにプログラム | |
JP4173755B2 (ja) | データ伝送サーバ | |
US20060291475A1 (en) | Selective forward error correction | |
EP1514378B1 (en) | Multimedia server with simple adaptation to dynamic network loss conditions | |
US20050013249A1 (en) | Redundant packets for streaming video protection | |
KR100908646B1 (ko) | 포워드 에러 정정 프레임 어셈블링 | |
US20060150055A1 (en) | Adaptive information delivery system using FEC feedback | |
KR20080059508A (ko) | 데이터 통신시스템, 데이터 송신장치, 데이터 송신방법 및패킷 사이즈 및 용장도 결정방법 | |
US9781488B2 (en) | Controlled adaptive rate switching system and method for media streaming over IP networks | |
CN106537855A (zh) | 减少视频电话中的延迟 | |
US9398256B2 (en) | Telecommunication end-point device data transmission controller | |
JP2006262288A (ja) | 映像データの配信サーバおよび映像データ配信方法 | |
JP5344541B2 (ja) | データ送信装置、送信方法及びプログラム | |
US10833710B2 (en) | Bandwidth efficient FEC scheme supporting uneven levels of protection | |
JP2005064648A (ja) | メディア伝送方法及びメディア伝送装置 | |
KR100535888B1 (ko) | 2차원 순방향 에러 정정방법 및 이를 이용한 데이터통신방법 | |
Chung-How et al. | Robust H. 263+ video for real-time Internet applications | |
Xu et al. | Development of a network adaptive H. 264/AVC medical video transmission system | |
TWI504245B (zh) | 視訊傳輸控制方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20110803 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110809 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20111108 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20120403 |