JP2014099708A - 送信装置、受信装置、送信方法、及び受信方法 - Google Patents
送信装置、受信装置、送信方法、及び受信方法 Download PDFInfo
- Publication number
- JP2014099708A JP2014099708A JP2012249442A JP2012249442A JP2014099708A JP 2014099708 A JP2014099708 A JP 2014099708A JP 2012249442 A JP2012249442 A JP 2012249442A JP 2012249442 A JP2012249442 A JP 2012249442A JP 2014099708 A JP2014099708 A JP 2014099708A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- unit
- check matrix
- ldpc
- data
- 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
Landscapes
- Detection And Prevention Of Errors In Transmission (AREA)
- Error Detection And Correction (AREA)
Abstract
【課題】帯域利用効率の低下を抑制できる送信装置を提供する。
【解決手段】ネットワークを介してパケットを送信する送信装置であって、データパケット生成部と、結合判定部と、検査行列導出部と、冗長パケット生成部と、送信部と、を備える。結合判定部は、生成されるフレームあたりのデータパケット数に基づいて、フレームを他のフレームと結合するか否かを判定する。検査行列導出部は、この判定結果に応じて、検査行列を導出する。
【選択図】図2
【解決手段】ネットワークを介してパケットを送信する送信装置であって、データパケット生成部と、結合判定部と、検査行列導出部と、冗長パケット生成部と、送信部と、を備える。結合判定部は、生成されるフレームあたりのデータパケット数に基づいて、フレームを他のフレームと結合するか否かを判定する。検査行列導出部は、この判定結果に応じて、検査行列を導出する。
【選択図】図2
Description
本開示は、送信装置、受信装置、送信方法、及び受信方法に関する。
データ伝送における誤り制御の1つの手法として、前方誤り訂正(FEC:Forward Error Correction)が知られている。
FECに関する技術として、下記のFECエンコード方法が知られている(例えば、非特許文献1参照)。この方法では、順次供給されたメディアパケットが有するペイロードそれぞれをバッファメモリに順次蓄える。また、バッファメモリに蓄えられたペイロードの数が規定数に達したか、又は、バッファメモリにペイロードが蓄え始め得たときからの時間が一定時間に達したかを検知する。
上記規定数に達したと検知された場合、バッファメモリに蓄えられた規定数のペイロードによりFEC演算を行って、FECのための第1の情報を生成する。そして、第1の情報を該第1の情報に対応するメディアパケットとともに出力する。
上記一定時間に達したと検知された場合に、バッファメモリに蓄えられたペイロードを用いてFEC演算を行って、FECのための第2の情報を生成する。そして、第2の情報を該第2の情報に対応するメディアパケットとともに出力する。
特許文献1の技術では、帯域利用効率の低下を抑制することは困難であった。
本開示は、上記事情に鑑みてなされたものであって、帯域利用効率の低下を抑制できる送信装置、受信装置、通信システム、送信方法、及び受信方法を提供する。
本開示の送信装置は、ネットワークを介してパケットを送信する送信装置であって、データがエンコードされたフレームからデータパケットを生成するデータパケット生成部と、前記データパケット生成部により生成される前記フレームあたりのデータパケット数に基づいて、前記フレームを他のフレームと結合するか否かを判定する結合判定部と、前記結合判定部により判定結果に応じて、検査行列を導出する検査行列導出部と、前記検査行列を用いて、前記データパケットから冗長パケットを生成する冗長パケット生成部と、前記データパケット及び前記冗長パケットを送信する送信部と、を備える。
本開示によれば、帯域利用効率の低下を抑制できる。
以下、本開示の実施形態について、図面を参照して説明する。
(本開示の一形態を得るに至った経緯)
例えばTV会議システムのIPベースのリアルタイムコミュニケーションシステムにおいて、高品質の映像伝送及び音声伝送の要望が高まっている。
IPネットワーク環境では、数%程度のパケットロスが発生する。そのため、例えば再送(ARQ:Automatic repeat−request)又はパケット消失訂正(FEC:Forward Error Correction)機能を用いて、例えば映像品質又は音声品質を確保している。リアルタイム性の要求が高い映像伝送システムの場合、RTT(Round Trip Time)が短い環境ではARQが有効であり、RTTが長い環境又はパケットロス率が高い環境ではFECが有効である。
また、近年、無線回線の高速化に伴い、モバイル環境における映像伝送システムが登場してきている。高速な無線回線には、例えばWiMAX(Worldwide Interoperability for Microwave Access),LTE(Long Term Evolution)が含まれる。
無線環境では、例えば端末の移動による電波環境の変化又はハンドオーバが頻繁に起こるため、有線環境と比較すると、通信品質(例えばパケットロス率又はRTT)が劣悪であることが多い。従って、無線環境において映像品質又は音声品質を確保する手段としては、FECが適している。
FECでは、例えば映像又は音声のデータパケットから冗長パケットを生成し、データパケットとともにネットワーク上に冗長パケットを送信する。データパケットに対し、より多くの冗長パケットを付与することにより、パケットロスに対する耐性を強化できる。ただし、無線環境では、有線環境に比べ伝送帯域が限られていることが多く、ネットワークのロス率に応じて適切な冗長パケット数を付与することが好ましい。
FECの代表的な方式として、例えば、Reed−Solomon符号及び低密度パリティ検査(LDPC:Low Density Parity Check)符号がある。
Reed−Solomon符号は、低冗長度であり、強いパケットロス耐性を得られる強力な符号化である反面、復号化のための演算処理が複雑になる。そのため、Reed−Solomon符号をリアルタイム映像伝送に適応する場合、短時間において計算処理するためのハードウェア実装又は高性能なCPUの実装が必要となり、端末への実装コストが高くなる。
LDPC符号については、Reed−Solomon符号に比べて演算量が小さく、ソフトウェアにより実装できる。また、LDPC符号は、データパケット数が多い状況では、Reed−Solomon符号を上回るパケットロス耐性を示す。
一方、無線環境では、1〜2Mbps程度の低帯域しか確保できない環境もある。このような低帯域の環境では、1ピクチャあたりのデータパケット数が少なくなるので、必ずしもデータパケット数が多い環境ではない。
本実施形態では、FEC符号として、LDPC符号を用いることを主に例示する。また、データパケット数をKとし、データパケット数Kと冗長パケット数とを合算した総パケット数をNとし、データパケット数:K、総パケット数:NのLDPC符号をLDPC(N,K)と示す。LDPC(N,K)は符号化パラメータの1つである。
例えば、LDPC(10,6)の場合、従来のFEC装置(エンコード側)は、映像データパケットを6個エンコーダから取得し、そのパケットから冗長パケットを4個生成する。従来のFEC装置は、取得された映像データパケットが6個未満であった場合、FEC装置は、6個目の映像データパケットが取得されるまでLDPC符号化せずにバッファし、6個目が取得されてからLDPC符号化する(バッファ符号化)。
しかし、エンコーダから取得されるパケット数が少ない状況では、映像データパケット数がLDPC符号化するための数に達するまでに時間を要し、長時間にわたりLDPC符号化できない。映像伝送システムのエンコーダは伝送帯域に応じてエンコードレートを調整することが多く、低いエンコードレートでは、1フレームから1パケットしか出力されないことがある。この場合、LDPC符号化に遅延が発生することがある。
特許文献1では、FEC装置がタイムアウト機能を有することにより、このようなLDPC符号化の遅延を抑制している。具体的には、一定時間内に出力された映像データパケット数が既定の数に達しない場合、不足分をヌルパケットにより補填し、LDPC符号化する。
しかし、特許文献1では、ヌルパケットを符号化に用いるので、映像データパケット数と冗長パケット数との比率(FEC強度)が変化し、帯域利用効率が低下する。
例えば、タイムアウト機能付きバッファ符号化を用いて、LDPC(10,6)の符号化を行うとする。また、FEC装置は、データパケットを2個取得した時点においてタイムアウトし、4個のヌルパケットを補填してLDPC符号化を行うとする。この場合、FEC装置は、データパケット2個と冗長パケット4個を送信する。ヌルパケットの数は、例えばヘッダに書き込まれる。
従って、LDPC符号化によるパケット数は6個であるが、データパケット(2個)に対し2倍の冗長パケット(4個)を送っていることに等しい。過剰な冗長パケットを付加して送信することにより、帯域利用効率が低下する。
以下では、帯域利用効率の低下を抑制できる送信装置、受信装置、送信方法、及び受信方法について説明する。
図1は本開示の実施形態における通信システム1000の構成例を示すブロック図である。通信システム1000は、送信装置100、受信装置300、及びIPネットワーク200を含む。送信装置100及び受信装置300は、IPネットワーク200を介して接続される。IPネットワーク200は、有線又は無線の回線を有する。通信システム1000は、例えばテレビ会議システム又は映像伝送システムに適用できる。
通信システム1000では、送信装置100と受信装置300との間において、データパケットとフィードバックパケットとが送受信される。フィードバックパケットは、フィードバック情報を含む。フィードバック情報は、例えば、RTTの情報及びパケットロス率の情報を含む。
次に、送信装置100の構成例について説明する。
図2は送信装置100の構成例を示すブロック図である。
図2は送信装置100の構成例を示すブロック図である。
送信装置100は、エンコーダ部110、QoS制御部120、パケット化部130、LDPC符号化演算部140、LDPC符号化処理決定部150、送信バッファ部160、RTPパケット送信部170、及びRTCPパケット受信部180を備える。
エンコーダ部110は、QoS制御部120からコーデックレートの情報を取得し、コーデックレートに応じて映像データをエンコードする。つまり、エンコーダ部110は、映像データをエンコード(符号化)し、映像ピクチャを生成する。
具体的には、エンコーダ部110は、QoS制御部120から通知されるエンコードレートに応じて、映像データを所定の符号化方式(例えばH.264)を用いて圧縮符号化する。エンコーダ部110は、符号化されたデータとしての映像ピクチャ(例えばIピクチャ、Pピクチャ)をパケット化部130に送る。映像ピクチャは、フレームの一例である。
QoS制御部120は、RTCPパケット受信部180からフィードバック情報を取得し、フィードバック情報に基づいて帯域推定する。例えば、QoS制御部120は、パケットロス率とRTTとから、ネットワーク帯域(例えば伝送レート)を推定する。QoS制御部120は、推定されたネットワーク帯域の情報をコーデックレートの情報としてエンコーダ部110に送る。
また、QoS制御部120は、フィードバック情報に含まれるパケットロス率及びRTTの情報を、LDPC符号化処理決定部150に送る。
また、QoS制御部120は、パケットロス率に基づいて、LDPC符号化においてどの程度冗長パケットを付与するかを示すFEC強度を導出する。例えば、データパケット数と冗長パケット数とが同数の場合、FEC強度=100である。QoS制御部120は、導出されたFEC強度をLDPC符号化処理決定部150に出力する。
パケット化部130は、エンコーダ部110によりエンコードされた映像データ(映像ピクチャ)を規定のパケットサイズにパケット化する。パケット化部130は、1ピクチャあたりのパケット数Kの情報をLDPC符号化処理決定部150に通知する。パケット化部130は、生成されたパケットをデータパケットとして、LDPC符号化演算部140と送信バッファ部160とに送る。
また、パケット化部130は、データパケットのヘッダを生成する。ヘッダには、例えばLDPC符号化情報が含まれる。パケット化部130は、データパケット生成部の一例である。LDPC符号化情報は、例えば、LDPC(N,K)により表わされる符号化パラメータの情報、後述する結合フラグの情報、具体的な検査行列の値、又は検査行列を生成するための初期シードの情報を含む。LDPC符号化情報により、検査行列の情報が受信装置300に通知される。
LDPC符号化演算部140は、LDPC符号化処理決定部150から取得した検査行列の情報に基づいて、LDPC符号化する。つまり、LDPC符号化演算部140は、LDPC検査行列の情報とデータパケットとを用いて、LDPC符号化し、冗長パケットを生成する。LDPC符号化演算部140は、冗長パケット生成部の一例である。LDPC符号化の詳細については後述する。
また、LDPC符号化演算部140は、LDPC符号化に必要なパケットを、送信バッファ部160にバッファされた過去のパケットから取得することもある。LDPC符号化演算部140は、生成された冗長パケットとデータパケットとをRTPパケット送信部170へ送る。
また、LDPC符号化演算部140の機能は、例えばLDPC符号器により実現される。
LDPC符号化処理決定部150は、例えば、データパケット数、RTT、及びパケットロス率の情報に基づいて、LDPC符号化に用いる検査行列を導出する。
また、LDPC符号化処理決定部150は、検査行列の生成に用いられる映像ピクチャを結合するか否かを決定する。LDPC符号化処理決定部150は、例えば、パケットロス率、RTT、及びデータパケット数の情報から、映像ピクチャを結合するか否かを決定する。映像ピクチャを結合すると、LDPC符号が結合される。
LDPC符号化処理決定部150は、映像ピクチャを結合する場合、映像ピクチャを結合するか否かを示す結合フラグをONにし、映像ピクチャを結合しない場合、結合フラグをOFFにする。LDPC符号化処理決定部150は、結合フラグの情報をLDPC符号化演算部140に送る。結合フラグの情報は、送信されるパケットのヘッダに含まれる。
また、LDPC符号化処理決定部150は、LDPC符号化に用いる検査行列を導出する。LDPC符号化処理決定部150は、結合フラグがOFFである場合には、映像ピクチャを結合せずに、検査行列を導出する。LDPC符号化処理決定部150は、結合フラグがONである場合には、映像ピクチャを結合した検査行列(結合検査行列)を導出する。結合検査行列は検査行列の一例である。
LDPC符号化処理決定部150は、映像ピクチャを結合する場合、例えば、エンコードされた映像ピクチャと送信バッファ部160により蓄積されたデータパケットに対応するピクチャを結合し、検査行列を導出する。これにより、パケットロスに対する耐性を強化できる。
LDPC符号化処理決定部150は、検査行列自体を内部テーブル(ルックアップテーブル)に保持しておき、必要時に内部テーブルから取得してもよい。検査行列は、FEC強度毎に内部テーブルに保持されてもよい。また、ピクチャ結合用の内部テーブルを非ピクチャ結合用の内部テーブルと分けてもよい。また、LDPC符号化処理決定部150は、初期シードを保持しておき、初期シードから検査行列を算出してもよい。送信装置100及び受信装置300は、検査行列の情報、又は、初期シード及び行列を生成するためのアルゴリズムの情報を予め共有してもよい。
LDPC符号化処理決定部150は、LDPC符号化するためのLDPC符号化情報をパケット化部130に送り、検査行列の情報をLDPC符号化演算部140に送る。
送信バッファ部160は、例えばRAM(Random Access Memory)により構成され、パケット化部130において処理済みのパケットを一時的に蓄積する。このパケットは、映像ピクチャが結合される場合に利用される。パケット化部130において処理済みのパケットは、RTPパケット送信部170により過去に送信されたパケットである。
RTPパケット送信部170は、RTP(Real−time Transport Protocol)を用いて、LDPC符号化演算部140からの冗長パケットとデータパケットとを、IPネットワーク200を介して受信装置300に送信する。
RTCPパケット受信部180は、RTCP(Real−time Transport Control Protocol)を用いて、IPネットワーク200を介して受信装置300により送信されたフィードバックパケットを受信する。
また、RTCPパケット受信部180は、フィードバックパケットに含まれるフィードバック情報を抽出する。フィードバック情報は、例えばパケットロス率の情報及びRTTの情報を含む。RTCP受信部101は、抽出されたフィードバック情報をQoS制御部120に送る。RTTは、送信装置100と受信装置300との間における往復伝送時間の一例である。
次に、受信装置300の構成例について説明する。
図3は受信装置300の構成例を示すブロック図である。
図3は受信装置300の構成例を示すブロック図である。
受信装置300は、RTPパケット受信部310、受信バッファ部320、ロス検出部330、LDPC復号処理決定部340、復号時刻監視部350、LDPC復号演算部360、及びデコード部370を備える。また、受信装置300は、フィードバック生成部380及びRTCPパケット送信部390を備える。
RTPパケット受信部310は、RTPを用いて、IPネットワーク200を介して送信装置100からデータパケット及び冗長パケットを受信する。また、RTPパケット受信部310は、データパケット及び冗長パケット(受信パケット)を、受信バッファ部320及びロス検出部330に送る。
また、RTPパケット受信部310は、受信パケットのヘッダに含まれる時刻情報を、フィードバック生成部380に送る。この時刻情報は、送信装置100による送信時刻の情報を含む。また、RTPパケット受信部310は、受信パケットのヘッダに含まれるLDPC符号化情報を、LDPC復号処理決定部340に送る。LDPC符号化情報は、符号化パラメータ及び結合フラグの情報を含む。
受信バッファ部320は、例えばRAM(Random Access Memory)により構成され、受信されたデータを蓄積する。このデータは、映像ピクチャが結合された場合のLDPC復号演算部360によるLDPC復号に利用される。また、復号時刻になる度に、受信バッファ部320に蓄積されたデータが削除されてもよい。
ロス検出部330は、RTPパケット受信部310からのパケットのRTPシーケンス番号を取得し、パケット(データパケット又は冗長パケット)のロスを検出する。ロス検出部330は、例えば、受信パケットのヘッダに含まれるシーケンス番号の連続性を確認することにより、パケットロスを検出する。
ロス検出部330は、パケットのロスが検出された場合、パケットロスの有無を示すパケットロスフラグをONにし、パケットのロスが検出されなかった場合、パケットロスフラグをOFFにする。ロス検出部330は、パケットロスフラグをLDPC復号処理決定部340に送る。
また、ロス検出部330は、受信パケット数とロスパケット数とからパケットロス率を算出し、パケットロス率の情報をフィードバック生成部380へ送る。このパケットロス率は、IPネットワーク200におけるパケットロス率に相当する。
LDPC復号処理決定部340は、ロス検出部330からパケットロスフラグの情報を受け取り、RTPパケット受信部310から符号化パラメータ及び結合フラグの情報を受け取り、復号時刻監視部350から復号時刻の情報を受け取る。
LDPC復号処理決定部340は、図示しないタイマが復号時刻になると、RTP受信部201からのLDPC符号化情報に基づいて、LDPC復号に用いる検査行列を導出する。LDPC復号処理決定部340は、導出された検査行列の情報をLDPC復号演算部360に送る。復号時刻は、デコード部370によりデータパケットがデコードされる時刻である。また、所定期間毎に復号時刻となる。
例えば、LDPC復号処理決定部340は、結合フラグがONであり、パケットロスフラグがONである場合、結合検査行列を導出する。また、例えば、LDPC復号処理決定部340は、LDPC符号化情報に具体的な結合検査行列の値が含まれる場合、その結合検査行列に基づいてLDPC復号に用いる検査行列を導出する。また、LDPC復号処理決定部340は、検査行列を生成するための初期シードを取得し、所定のアルゴリズムを用いて検査行列を算出してもよい。
また、送信装置100と同様に、LDPC復号処理決定部340は、検査行列自体を内部テーブルに保持しておき、必要時に内部テーブルから取得してもよい。検査行列は、FEC強度毎に内部テーブルに保持されてもよい。また、ピクチャ結合用の内部テーブルを非ピクチャ結合用の内部テーブルと分けてもよい。また、LDPC復号処理決定部340は、初期シードを保持しておき、初期シードからLDPC検査行列を算出してもよい。送信装置100及び受信装置300は、LDPC検査行列の情報、又は、初期シード及び行列を生成するためのアルゴリズムの情報を予め共有してもよい。
復号時刻監視部350は、復号時刻を監視し、復号時刻の情報をLDPC復号処理決定部340に送る。
LDPC復号演算部360は、LDPC復号処理決定部340から通知された検査行列の情報に基づきLDPC復号し、復号された映像データをデコード部370に送信する。例えば、LDPC復号演算部360は、検査行列の情報、データパケット、及び冗長パケットを用いて、ロスパケットの回復処理(LDPC復号)を行う。LDPC復号は、FEC復号の一例であり、誤り訂正復号の一例である。
また、映像ピクチャが結合された結合LDPC符号である場合、LDPC復号演算部360は、受信バッファ部320にバッファされたデータパケット又は冗長パケットを用いて、LDPC復号する。
また、LDPC復号演算部360は、LDPC復号されたパケットをデパケット化し、映像ピクチャを生成する。
デコード部370は、所定時間毎に、LDPC復号演算部360からの映像ピクチャをデコードすることにより、映像データを出力する。デコード部370は、映像ピクチャのデコードのタイミングを復号時刻として、復号時刻の情報を復号時刻監視部350に送る。
フィードバック生成部380は、RTPパケット受信部310から受信パケットを受信した受信時刻の情報を受け取り、ロス検出部330からパケットロス率の情報を受け取る。フィードバック生成部380は、この受信時刻及びパケットロス率の情報を含むフィードバックパケットを生成し、フィードバックパケットをRTCPパケット送信部390に送る。
RTCPパケット送信部390は、フィードバック生成部380からフィードバックパケットを受け取る。RTCPパケット送信部390は、RTCPを用いて、IPネットワーク200を介してフィードバックパケットを送信装置100に送信する。
次に、通信システム1000の動作概要について説明する。
図4は、通信システム1000の動作例の概要図である。
図4は、通信システム1000の動作例の概要図である。
送信装置100は、映像データをエンコードした後にパケット化する。送信装置100は、フィードバック情報を基に帯域推定し、帯域推定値を、エンコードに用いるコーデックレートとする。送信装置100は、パケット化されたデータパケットをLDPC符号化した後、IPネットワーク200に送信する。
送信装置100は、1ピクチャあたりのデータパケット数、RTT、パケットロス率に基づいて、例えば、符号化パラメータ及び複数の映像ピクチャを結合するか否かを決定する。
受信装置300は、IPネットワーク200からのパケット受信後、RTPシーケンス番号を基にパケットロスが発生したか否かを判定する。受信装置300は、この判定結果に基づき、LDPC復号する。受信装置300は、例えば、パケットロスの有無、符号化パラメータの情報を基に、LDPC復号する。
また、受信装置300は、様々な遅延の影響を吸収するため、映像ピクチャの再生に間に合う範囲における限界まで待機してから、LDPC復号する。上記限界は、例えば、映像ピクチャから映像データに定期的にデコードされる時刻(復号時刻)である。上記遅延には、例えば、IPネットワーク200におけるネットワーク遅延、又は受信装置300における処理遅延を含む。受信装置300は、LDPC復号後のデータパケットをデコーダに送り、映像データにデコードする。
受信装置300は、LDPC復号と並行して、フィードバックパケットの送信を行う。フィードバックパケットの送信では、受信装置300は、送信装置100に対し、IPネットワーク200のRTT及びパケットロス率の情報を含むフィードバック情報を通知する。送信装置100は、フィードバック情報に基づいて帯域推定できる。
次に、送信装置100の具体的な動作について説明する。
まず、図15を用いて、送信装置100の動作例の概要について説明する。
まず、図15を用いて、送信装置100の動作例の概要について説明する。
データパケット生成部は、データがエンコードされたフレームからデータパケットを生成する(S11)。データパケット生成部は、例えばパケット化部130である。
続いて、結合判定部は、データパケット生成部により生成されるフレームあたりのデータパケット数に基づいて、フレームを他のフレームと結合するか否かを判定する(S12)。結合判定部は、例えばLDPC符号化処理決定部150である。
続いて、検査行列導出部は、結合判定部による判定結果に応じて、検査行列を導出する(S13)。検査行列導出部は、例えばLDPC符号化処理決定部150である。
続いて、冗長パケット生成部は、検査行列を用いて、データパケットから冗長パケットを生成する(S14)。冗長パケット生成部は、例えばLDPC符号化演算部140である。
続いて、送信部は、データパケット及び冗長パケットを送信する(S15)。送信部は、例えばRTPパケット送信部170である。
次に、送信装置100によるLDPC符号化処理について説明する。
図5は、検査行列の決定処理の一例を示すフローチャートである。
図5は、検査行列の決定処理の一例を示すフローチャートである。
LDPC符号化処理決定部150は、パケット化部130から通知された1ピクチャ辺りのデータパケット数Kと、所定の閾値θKと、を比較し、データパケット数Kが所定の閾値θKよりも小さいか否かを判定する(S101)。
また、LDPC符号化処理決定部150は、QoS制御部120から通知されたRTTと所定の閾値θDとを比較し、RTTが所定の閾値θDよりも小さいか否かを判定する(S102)。
データパケット数Kが所定の閾値θKよりも小さく、かつ、RTTが所定の閾値θDよりも小さい場合、LDPC符号化処理決定部150は、結合フラグをONとする(S103)。
一方、データパケット数Kが所定の閾値θK以上である場合、又は、RTTが所定の閾値θD以上である場合、LDPC符号化処理決定部150は、結合フラグをOFFとする(S104)。
S104において結合フラグをOFFにするのは、1ピクチャあたりのデータパケット数がピクチャ結合しなくても大きい場合、結合LDPC符号を使わなくても、LDPC復号の回復率を所望の水準に確保できるためである。また、RTTが長い環境では、パケット受信後すぐにLDPC復号するため、復号時刻を考慮すると結合LDPCによる改善効果が得られないことがあるためである。
なお、結合フラグの情報(例えばON/OFFの情報)は、例えば、パケット化部130によりLDPCパケットのヘッダ部分に記述される。
S103又はS104において結合フラグのON/OFFの決定後、LDPC符号化処理決定部150は、内部テーブルを参照して、検査行列を決定する(S105)。LDPC符号化処理決定部150の内部テーブルには、例えば、FEC強度毎における検査行列が保存されている。LDPC符号化処理決定部150は、例えば、ネットワークのパケットロス率に応じて、特定のFEC強度の検査行列を選択する。
FEC強度が大きい検査行列が選択されると、パケットロスが頻発する高パケットロス環境においても、通信システム1000の品質目標として設定される目標パケットロス率Ptargetを達成できる可能性が高くなる。一方、FEC強度が小さい行列が選択されると、冗長パケット数が少なくなり、伝送帯域を圧迫することを防止できる。
LDPC符号化処理決定部150は、結合フラグがONの場合には、今回の検査行列の要素を、先のパケットに対するLDPC符号化に用いられた検査行列の要素に結合させ、検査行列を設計する。このように、後続のパケット側のLDPC符号化処理を変更するように検査行列を結合するので、先のパケットのLDPC符号化は、後続のパケットに対するLDPC符号化用の結合フラグのON/OFFの影響を受けない。この点、時間的に後続のパケットを待機してLDPC符号化するバッファ符号化とは異なる。
なお、LDPC符号化処理決定部150は、IPネットワーク200の状況(例えばRTT)を考慮せずに、映像ピクチャを結合するか否かを決定してもよい。つまり、S102の処理は省略できる。
送信装置100は、データパケット数に応じて映像ピクチャを結合するか否かを決定することにより、ロス耐性が不足すると推定される場合に、映像ピクチャを結合できるので、所望のロス耐性が得られる。また、送信装置100は、RTTに応じて映像ピクチャを結合するか否かを決定することにより、受信装置300の復号時刻を考慮して映像ピクチャを結合できるので、受信装置300が復号時刻を超過してパケットを受信する確率を低下できる。
また、検査行列の情報は、上述のように内部テーブルに格納されていない場合であっても、内部テーブルに格納された情報(例えば初期シードの情報)から、所望の検査行列が生成されてもよい。
図6は、映像ピクチャの結合なしの場合のLDPC符号化処理のイメージ図である。
図6では、データパケット数K=3とし、FEC強度=100とする。また、LDPC符号化演算部140が、以下の式(1)に示される検査行列を用いて、LDPC符号化処理することを想定する。この検査行列Hは、LDPC符号化処理決定部150により決定される。
また、LDPC符号化演算部140は、式(1)により示される検査行列Hに対し、データパケットD[0],D[1],D[2]、及び冗長パケットP[0],P[1],P[2]が、以下の数式(2)の関係を満たすように冗長パケットを生成する。
つまり、LDPC符号化演算部140は、以下の式(3)〜(5)を用いて、冗長パケットを生成する。
図7は、映像ピクチャの結合ありの場合のLDPC符号化処理のイメージ図である。
図7では、LDPC符号化演算部140に、1ピクチャあたりのデータパケット数K=2の映像データの後に、1ピクチャあたりのデータパケット数K=1の映像データが到来することを想定する。つまり、1ピクチャ目のデータパケットにD[0]、D[1]が含まれ、2ピクチャ目のデータパケットにD[2]が含まれることを想定する。
1ピクチャ目の符号化パラメータは、LDPC(4,2)である。2ピクチャ目の符号化パラメータは、(2,1)である。1ピクチャ目のLDPC符号の生成に用いる検査行列H11は、以下の式(6)により示される。2ピクチャ目のLDPC符号の生成に用いる検査行列H12は、以下の式(7)により示される。
例えば図7における閾値θK=3とすると、上記映像データが到来する場合、映像ピクチャを結合しない。つまり、LDPC符号化演算部140は、1ピクチャ目を(N,K)=(4,2)としてLDPC符号化する。また、LDPC符号化演算部140は、2ピクチャ目を(N,K)=(2,1)としてLDPC符号化する。
これに対し、例えば図7における閾値θK=3とすると、上記映像データが到来する場合、映像ピクチャを結合する。つまり、LDPC符号化演算部140は、1ピクチャ目及び2ピクチャ目が結合された以下の式(8)により示される結合検査行列H13を用いて、(N,K)=(6,3)としてLDPC符号化する。
結合検査行列H13を生成する際に、初めて値が設定される要素D100の部分及び要素P100の部分には、任意の値が設定される。図7の例では、2ピクチャ目のデータパケットであるD[2]と、D[2]の直前のD[1]とを用いて、冗長パケットP[2]が生成されることを示している。つまり、LDPC符号化演算部140は、符号化対象のデータパケットと、直前のデータパケットと、を用いて、冗長パケットを生成してもよい。なお、LDPC符号化演算部140は、過去に処理したデータパケットであって直前ではないデータパケットを用いて、冗長パケットを生成してもよい。
映像ピクチャを結合する場合、ピクチャ結合なしの場合のLDPC符号に比べて、符号化パラメータ(N,K)を大きくでき、つまり検査行列の要素数を大きくできる。従って、ピクチャ結合ありの場合、符号化のバリエーションが多様化し、ピクチャ結合なしの場合に比べてパケットロスの回復率を改善できる。
また、2ピクチャ目における映像ピクチャの結合処理は、1ピクチャ目と2ピクチャ目のピクチャ結合となるので、1ピクチャ目のLDPC符号化に影響を与えない。つまり、1ピクチャ目の符号化パラメータは、LDPC(4,2)のままである。従って、バッファ符号化と異なり、LDPC符号化における遅延を抑制できる。
送信装置100によれば、過剰な冗長パケットを付加してパケットを送信することがなく、帯域利用効率の低下を抑制できる。また、図8(A)に示すように、他のパケットの情報も用いてLDPC符号化するので、符号化のバリエーションを多様化できる。従って、図8(B)に示す他のパケットの情報を用いずにパケットを送信する場合と比較すると、パケットロスに対する耐性を強化できる。
また、図8(A)に示すように、既に送信されたパケットの情報(過去情報)を用いてLDPC符号化するので、LDPC符号化における遅延を抑制できる。この場合、受信装置300において映像ピクチャをデコードする際に、より多くの映像ピクチャを結合してLDPC復号できる。従って、図8(C)に示す後続のパケットを取得してからLDPC符号化(バッファ符号化)する場合と比較すると、ネットワーク遅延に対する耐性を強化できる。
なお、図8(A)〜(C)では、D[0]〜D[3]をData[0]〜Data[3]と示している。また、P[0]〜P[3]をFEC[0]〜FEC[3]と示している。
次に、受信装置300の具体的な動作について説明する。
まず、図16を用いて、受信装置300の動作例の概要について説明する。
まず、図16を用いて、受信装置300の動作例の概要について説明する。
受信部は、パケットを受信する(S21)。受信部は、例えばRTPパケット受信部310である。
続いて、検査行列導出部は、受信パケットに含まれる、検査行列の生成のためにフレームが結合されたか否かを示す情報に基づいて、検査行列を導出する(S22)。検査行列導出部は、例えばLDPC復号処理決定部340である。
続いて、復号部は、受信されたデータパケット及び冗長パケットと、検査行列と、に基づいて、誤り訂正復号する(S23)。復号部は、例えばLDPC復号演算部360である。
次に、受信装置300によるLDPC復号処理について説明する。
図9は、検査行列の決定処理の一例を示すフローチャートである。
図9は、検査行列の決定処理の一例を示すフローチャートである。
まず、LDPC復号処理決定部340は、ロス検出部330からパケットロスフラグを受け取り、パケットロスフラグがONであるか否かを判定する(S201)。
なお、ロス検出部330は、パケットロスが発生した場合に限り、パケットロスフラグをLDPC復号処理決定部340に通知してもよい。この場合、LDPC復号処理決定部340は、ロス検出部330からパケットロスフラグを受け取ったか否かを判定する。
パケットロスフラグがOFFである場合、パケットロスが発生しておらず、LDPC復号することなく全てのデータパケットが正常に受信されている。従って、LDPC復号演算部360によりパケットロスを回復させる必要がないので、図9の処理を終了する。なお、パケットロスフラグがOFFであることを確認する代わりに、パケットロスフラグを受け取らなかったことを確認してもよい。
パケットロスフラグがONである場合、LDPC復号処理決定部340は、図示しないタイマを参照し、現在時刻が復号時刻であるか否かを判定する(S202)。
復号時刻でない場合、LDPC復号処理決定部340は、受信バッファ部320へ受信パケットをバッファさせる(S203)。なお、復号時刻になるまでは、検査行列の決定を待機する。
一方、現在時刻が復号時刻である場合、LDPC復号処理決定部340は、受信パケットに含まれる結合フラグがONであるかOFFであるかを判定する(S204)。結合フラグがON、つまり結合LDPC符号を利用している場合、先に受信された映像ピクチャと結合してからLDPC復号することにより、パケットロスの回復率を改善できる。
結合フラグがONである場合、LDPC復号処理決定部340は、結合可能な映像ピクチャ、つまり受信バッファ部320にバッファされたパケットを結合して検査行列を決定する(S205)。この場合、LDPC復号処理決定部340は、例えば、結合される映像ピクチャに含まれるデータパケット数K、パケットロス率、及び映像ピクチャの結合数に応じて、結合検査行列を決定する。これにより、現在時刻から復号時刻まで時間的猶予がある場合、結合数(例えば2ピクチャ又は3ピクチャ)を例えば復号時刻に応じて増加できる。従って、データパケット数を増加でき、検査行列の要素のバリエーションを多様化できるので、パケットロスの回復率を改善できる。なお、結合数に応じて結合検査行列を決定するとは、例えば、どのピクチャと結合するか(例えば直前のピクチャと結合、2つ前のピクチャと結合)に応じて結合検査行列を決定することを含む。
結合フラグがOFFである場合、LDPC復号処理決定部340は、映像ピクチャを先に受信された映像ピクチャと結合せずに、LDPC復号する(S206)。この場合、LDPC復号処理決定部340は、例えばデータパケット数及びパケットロス率に応じて、検査行列を決定する。
結合検査行列では、今回の検査行列の要素が、先の映像ピクチャのLDPC復号に用いられた検査行列の要素と結合される。従って、時間的に後続するピクチャを受信するまでLDPC復号できないという状況を回避でき、LDPC復号における遅延を抑制できる。
また、復号時刻までの時間的猶予は、例えばIPネットワーク200の遅延によって変化する。特に無線ネットワークを利用する場合、遅延の変動幅が予期できないことがある。受信装置300により結合数を決定することにより、遅延変動を加味した上で、最大限データパケット数Kを大きく確保できる。結合数は、例えば、復号時刻に達した時点において、結合フラグがONであるピクチャ数により決定される。
このような検査行列の決定処理によれば、LDPC復号処理決定部340は、受信バッファ部320に蓄積されたパケットに対応する複数のピクチャを結合し、検査行列を導出してもよい。これにより、可能な限り検査行列に用いるデータパケット数を多くしてLDPC復号でき、パケットロスに対する耐性を強化できる。
なお、LDPC復号処理決定部340は、結合フラグがONの場合、例えば内部テーブルからピクチャ結合ありの結合検査行列を選択する。LDPC復号処理決定部340は、結合フラグがOFFの場合、例えば内部テーブルからピクチャ結合なしの検査行列を選択する。
なお、符号化パラメータの情報は、LDPC符号化情報に含まれて送信装置100から通知される。従って、LDPC復号処理決定部340は、結合フラグがONの場合、結合LDPC符号に含まれる各LDPC符号の符号化パラメータに応じて、特定のFEC強度の検査行列を選択する。また、結合フラグがOFFの場合、LDPC符号の符号化パラメータに応じて、特定のFEC強度の検査行列を選択する。
図10は、映像ピクチャの結合ありの場合のLDPC復号処理のイメージ図である。なお、図10では、送信装置100において、2つの映像ピクチャが、先の式(5),(6)において示された検査行列を用いて、LDPC符号化が行われたことを想定している。受信装置300は、式(5),(6)において示された検査行列、又はこの検査行列を生成するための情報(例えば初期シード)を、例えばLDPC符号化情報から得る。なお、送信装置100において、2ピクチャ目が1ピクチャ目と結合されたか否かは問わない。
図10では、受信装置300がパケット受信し、LDPC復号するための検査行列を示す。図10では、データパケットD[1]及び冗長パケットP[1]がIPネットワーク200においてロスしている。そのため、ピクチャ結合無しの検査行列では、LDPC復号のためのデータが不足するので、ロスパケットを回復できない。
この場合であっても、1ピクチャ目のパケット受信から復号時刻まで時間的猶予があり、2ピクチャ目のパケットを受信した場合、先に説明した式(8)の検査行列を用いて、LDPC復号できる。この場合、LDPC復号演算部360は、以下の式(9)のように、LDPC復号する。
なお、式(8)に示した結合検査行列の情報は、送信装置100と同様の方法によりLDPC復号処理決定部340が生成してもよいし、LDPC符号化情報に含めて送信装置100から通知されてもよい。
次に、復号時刻tdと映像ピクチャの復号範囲との関係について説明する。
図11(A),(B)は、従来方法によりLDPC符号化した場合に送信又は受信されるパケットを時系列に示す図である。
図11(A),(B)では、第1のピクチャにおけるデータパケットはD[0]であり、データパケット数はK=1である。第2のピクチャにおけるデータパケットはD[1],D[2]であり、データパケット数はK=2である。第3のピクチャにおけるデータパケットはD[3]であり、データパケット数はK=1である。なお、図面では、データパケットD[x]を「x」と示して無背景にしており、冗長パケットP[x]を「x」と示して背景をドットパターンにしている。
図11(A),(B)では、送信側により送信されたパケットと、遅延が小さい場合の受信側による受信されるパケットと、遅延が大きい場合の受信側により受信されるパケットと、を時系列に示している。
なお、受信側において、時間軸(t軸)よりも上側に示されたパケット(例えば、P[0]、D[1]、D[2])は、受信側に到達したパケットを示す。また、時間軸よりも下側に示されたパケット(例えば、D[0])は、受信側に到達しなかったパケット、つまりロスしたパケットを示している。
図11(A)では、パケットをバッファせずに、LDPC符号化及びLDPC復号することを想定している。この場合、遅延が小さい場合でも大きい場合でも、復号時刻tdまでに、パケットが送信側から受信側へ到達する。従って、送信側が送信したパケットの多くを用いて、LDPC復号できる。遅延は、例えばネットワーク遅延又は処理遅延を含む。
ただし、パケットをバッファしないので、1ピクチャあたりのデータパケット数が小さい場合には、LDPC符号化及びLDPC復号に用いる符号長(データパケット数)は小さいままであり、パケットロスに対する耐性を強化できない。
図11(B)では、パケットをバッファして、LDPC符号化及びLDPC復号することを想定している。この場合、遅延が小さい場合には、復号時刻tdまでに、パケットが送信側から受信側へ到達するが、遅延が大きい場合には、復号時刻tdまでに、パケットが送信側から受信側へ到達しない。ここでは、遅延の程度は、図11(A)と同程度を想定している。図11(B)では、受信側は、LDPC符号化した際の符号長と同じ符号長を用いる必要があるので、LDPC復号できないことになる。
図12は、従来方法によりパケットをバッファしてLDPC符号化した場合に送信又は受信されるパケットの他例を時系列に示し、LDPC復号結果を示す図である。
図12では、D[0]及びD[2]がパケットロスしている。また、遅延が小さい場合、復号時刻tdまでに送信側からの全てのパケットが受信側へ到達している。また、遅延が大きい場合、復号時刻tdまでに送信側から送られるパケットのうち、データパケットD[3]、冗長パケットP[0]〜P[3]が受信側へ到達していない。
従って、遅延が小さい場合には、D[0]及びD[2]がロスしているが、受信側は、LDPC復号によりD[0]及びD[2]を復元できる。一方、遅延が大きい場合には、D[0]及びD[2]がロスしており、D[3]は復号時刻tdまでに到達せず、受信側はLDPC復号できない。すなわち、受信側は、D[0]及びD[2]を復元できず、D[1]のみを得られる。
図13は、実施形態におけるLDPC符号化と送信又は受信されるパケットとの一例を時系列に示す図である。
図13では、第1のピクチャにおけるデータパケットはD[0]であり、データパケット数はK=1である。第2のピクチャにおけるデータパケットはD[1],D[2]であり、データパケット数はK=2である。第3のピクチャにおけるデータパケットはD[3]であり、データパケット数はK=1である。なお、図13では、データパケットD[x]を「x」と示して無背景にしており、冗長パケットP[x]を「x」と示して背景をドットパターンにしている。
図13では、送信装置100により送信されたパケットと、遅延が小さい場合、中程度である場合、及び大きい場合の受信装置300により受信されるパケットと、を時系列に示している。
図13では、遅延が小さい場合、復号時刻tdまでに送信装置100からの全てのパケットが受信装置300に到達している。遅延が中程度の場合、復号時刻tdまでに、データパケットD[3]及び冗長パケットP[3]以外のパケットが受信装置300に到達している。遅延が大きい場合、復号時刻tdまでに、データパケットD[0]及び冗長パケットP[0]が受信装置300に到達している。
従って、遅延が小さい場合、受信装置300は、データパケットD[0]〜D[3]及び冗長パケットP[0]〜P[3]を用いて、LDPC復号する。つまり、LDPC復号に用いるデータパケット数K=4である。この場合、LDPC復号に用いられる結合検査行列H21は、以下の式(11)により示される。(式11)と(式10)は同じである。
また、遅延が中程度の場合、受信装置300は、データパケットD[0]〜D[2]及び冗長パケットP[0]〜P[2]を用いて、LDPC復号する。つまり、LDPC復号に用いるデータパケット数K=3である。この場合、LDPC復号に用いられる結合検査行列H22は、以下の式(12)により示される。
また、遅延が大きい場合、受信装置300は、データパケットD[0]及び冗長パケットP[2]を用いて、LDPC復号する。つまり、LDPC復号に用いるデータパケット数K=1である。この場合、LDPC復号に用いられる検査行列H23は、以下の式(13)により示される。
図14は、実施形態におけるLDPC符号化と送信又は受信されるパケットとの一例を時系列に示し、LDPC復号結果例を示す図である。図13と異なる点は、D[0]及びD[2]がパケットロスしている点である。
遅延が小さい場合、D[0]及びD[2]がロスしているが、受信装置300は、LDPC復号によりD[0]及びD[2]を復元できるので、D[0]〜D[3]を得られる。
一方、遅延が中程度の場合には、D[0]及びD[2]がロスしており、D[3]及びP[3]が復号時刻tdまでに到達していない。この場合であっても、受信されたデータパケットD[1]及び冗長パケットP[0],P[1],P[2]を用いてLDPC復号でき、D[0]及びD[2]を復元できる。なお、受信装置300は、データパケットD[3]は復元できないが、復号時刻tdまでに到達したパケットを最大限に利用して、効率良くLDPC復号できる。図14には、LDPC復号結果も示されている。
このように、受信装置300によれば、受信されたデータパケット数Kが少ない状況でも、LDPC復号による遅延を増加させず、LDPC復号に用いるデータパケット数Kを増加できるので、LDPC復号の回復性能を改善できる。また、遅延変動が激しいIPネットワーク200(例えば無線ネットワーク)において、受信装置300が結合LDPC符号を利用するか否かを最終判断するので、受信パケットを利用してデータパケット数を実現可能な範囲において最多とし、LDPC復号できる。
また、映像伝送では、復号時刻までに届いたパケットを用いて、復号する。また、例えばIPネットワーク200に応じて適切な符号長(例えばデータパケット数)によりLDPC符号化していない場合、復号時刻より遅れて冗長パケットが到着する場合がある。特に、無線環境ではRTTが急激に変動することがあり、復号時刻を超える可能性が高い。また、無線環境が劣悪である場合、画質を低下させることにより、1ピクチャあたりのデータパケット数が小さい状況が継続することも想定される。受信装置300によれば、このような低帯域環境又は遅延変動が大きい環境であっても、好適にLDPC復号できる。
本開示は、上記実施形態の構成に限られない。特許請求の範囲において示した機能、または上記実施形態の構成が持つ機能が達成できる構成であれば、どのようなものであっても適用できる。
上記実施形態では、RTP及びRTCPを用いてパケットを通信することを例示したが、RTP、RTCP以外のプロトコルを用いてパケットを通信してもよい。
上記実施形態では、LDPC符号化を行うことを例示したが、LDPC以外であっても、検査行列を用いるFEC符号化であればよい。
上記実施形態では、受信バッファ部320が、復号時刻まで受信パケットを蓄積することを示したが、復号時刻に至るまでのパケットのうち一部を省略して蓄積してもよい。また、受信バッファ部320が、復号時刻以前の所定時刻までに受信された受信パケットを蓄積してもよい。
上記実施形態では、データとして映像データを例示したが、例えば音声データ、音声データと映像データとの組み合わせであってもよい。
また、上記実施形態では、本開示をハードウェアによって構成する場合を例にとって説明したが、本開示はハードウェアとの連携においてソフトウェアでも実現することも可能である。
また、上記実施形態の説明に用いた各機能ブロックは、典型的には集積回路であるLSIとして実現される。これらは個別に1チップ化されてもよいし、一部または全てを含むように1チップ化されてもよい。ここでは、LSIとしてもよいし、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称してもよい。
また、集積回路化の手法はLSIに限るものではなく、専用回路または汎用プロセッサで実現してもよい。例えば、LSI製造後にプログラムすることが可能なFPGA(Field Programmable Gate Array)、LSI内部の回路セルの接続、又は、設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
(開示の一態様の概要)
本開示の第1の送信装置は、
ネットワークを介してパケットを送信する送信装置であって、
データがエンコードされたフレームからデータパケットを生成するデータパケット生成部と、
前記データパケット生成部により生成される前記フレームあたりのデータパケット数に基づいて、前記フレームを他のフレームと結合するか否かを判定する結合判定部と、
前記結合判定部により判定結果に応じて、検査行列を導出する検査行列導出部と、
前記検査行列を用いて、前記データパケットから冗長パケットを生成する冗長パケット生成部と、
前記データパケット及び前記冗長パケットを送信する送信部と、
を備える。
本開示の第1の送信装置は、
ネットワークを介してパケットを送信する送信装置であって、
データがエンコードされたフレームからデータパケットを生成するデータパケット生成部と、
前記データパケット生成部により生成される前記フレームあたりのデータパケット数に基づいて、前記フレームを他のフレームと結合するか否かを判定する結合判定部と、
前記結合判定部により判定結果に応じて、検査行列を導出する検査行列導出部と、
前記検査行列を用いて、前記データパケットから冗長パケットを生成する冗長パケット生成部と、
前記データパケット及び前記冗長パケットを送信する送信部と、
を備える。
また、本開示の第2の送信装置は、第1の送信装置であって、
前記検査行列導出部は、前記結合判定部により他のフレームと結合すると判定された場合、エンコードされたフレームと前記送信部により送信されたデータパケットのフレームとを結合し、前記検査行列を導出する。
前記検査行列導出部は、前記結合判定部により他のフレームと結合すると判定された場合、エンコードされたフレームと前記送信部により送信されたデータパケットのフレームとを結合し、前記検査行列を導出する。
また、本開示の第3の送信装置は、第1または第2の送信装置であって、
前記結合判定部は、当該送信装置と前記パケットを受信する受信装置との間における往復伝送時間に基づいて、エンコードされたフレームと他のフレームとを結合するか否かを判定する。
前記結合判定部は、当該送信装置と前記パケットを受信する受信装置との間における往復伝送時間に基づいて、エンコードされたフレームと他のフレームとを結合するか否かを判定する。
また、本開示の第4の受信装置は、
ネットワークを介してパケットを受信する受信装置であって、
パケットを受信する受信部と、
前記受信部により受信されたパケットに含まれる、検査行列の生成のためにフレームが結合されたか否かを示す情報に基づいて、前記検査行列を導出する検査行列導出部と、
前記受信部により受信されたデータパケット及び冗長パケットと、前記検査行列と、に基づいて、誤り訂正復号する復号部と、
を備える。
ネットワークを介してパケットを受信する受信装置であって、
パケットを受信する受信部と、
前記受信部により受信されたパケットに含まれる、検査行列の生成のためにフレームが結合されたか否かを示す情報に基づいて、前記検査行列を導出する検査行列導出部と、
前記受信部により受信されたデータパケット及び冗長パケットと、前記検査行列と、に基づいて、誤り訂正復号する復号部と、
を備える。
また、本開示の第5の受信装置は、第4の受信装置であって、
前記データパケットに対応するフレームがデコードされる復号時刻以前の所定時刻になるまで、前記パケットをバッファする受信バッファ部を備え、
前記検査行列導出部は、前記受信バッファ部に蓄積されたパケットに対応する複数のフレームを結合し、前記検査行列を導出する。
前記データパケットに対応するフレームがデコードされる復号時刻以前の所定時刻になるまで、前記パケットをバッファする受信バッファ部を備え、
前記検査行列導出部は、前記受信バッファ部に蓄積されたパケットに対応する複数のフレームを結合し、前記検査行列を導出する。
また、本開示の第6の送信方法は、
ネットワークを介してパケットを送信する送信装置における送信方法であって、
データがエンコードされたフレームからデータパケットを生成するステップと、
前記生成される前記フレームあたりのデータパケット数に基づいて、前記フレームを他のフレームと結合するか否かを判定するステップと、
前記判定の結果に応じて、検査行列を導出するステップと、
前記検査行列を用いて、前記データパケットから冗長パケットを生成するステップと、
前記データパケット及び前記冗長パケットを送信するステップと、
を有する。
ネットワークを介してパケットを送信する送信装置における送信方法であって、
データがエンコードされたフレームからデータパケットを生成するステップと、
前記生成される前記フレームあたりのデータパケット数に基づいて、前記フレームを他のフレームと結合するか否かを判定するステップと、
前記判定の結果に応じて、検査行列を導出するステップと、
前記検査行列を用いて、前記データパケットから冗長パケットを生成するステップと、
前記データパケット及び前記冗長パケットを送信するステップと、
を有する。
また、本開示の第7の受信方法は、
ネットワークを介してパケットを受信する受信装置における受信方法であって、
パケットを受信するステップと、
前記受信されたパケットに含まれる、検査行列の生成のためにフレームが結合されたか否かを示す情報に基づいて、前記検査行列を導出するステップと、
前記受信されたデータパケット及び冗長パケットと、前記検査行列と、に基づいて、誤り訂正復号するステップと、
を有する。
ネットワークを介してパケットを受信する受信装置における受信方法であって、
パケットを受信するステップと、
前記受信されたパケットに含まれる、検査行列の生成のためにフレームが結合されたか否かを示す情報に基づいて、前記検査行列を導出するステップと、
前記受信されたデータパケット及び冗長パケットと、前記検査行列と、に基づいて、誤り訂正復号するステップと、
を有する。
本開示は、帯域利用効率の低下を抑制できる送信装置、受信装置、送信方法、及び受信方法等に有用である。
1000 通信システム
100 送信装置
110 エンコーダ部
120 QoS制御部
130 パケット化部
140 LDPC符号化演算部
150 LDPC符号化処理決定部
160 送信バッファ部
170 RTPパケット送信部
180 RTCPパケット受信部
200 IPネットワーク
300 受信装置
310 RTPパケット受信部
320 受信バッファ部
330 ロス検出部
340 LDPC復号処理決定部
350 復号時刻監視部
360 LDPC復号演算部
370 デコード部
100 送信装置
110 エンコーダ部
120 QoS制御部
130 パケット化部
140 LDPC符号化演算部
150 LDPC符号化処理決定部
160 送信バッファ部
170 RTPパケット送信部
180 RTCPパケット受信部
200 IPネットワーク
300 受信装置
310 RTPパケット受信部
320 受信バッファ部
330 ロス検出部
340 LDPC復号処理決定部
350 復号時刻監視部
360 LDPC復号演算部
370 デコード部
Claims (7)
- ネットワークを介してパケットを送信する送信装置であって、
データがエンコードされたフレームからデータパケットを生成するデータパケット生成部と、
前記データパケット生成部により生成される前記フレームあたりのデータパケット数に基づいて、前記フレームを他のフレームと結合するか否かを判定する結合判定部と、
前記結合判定部により判定結果に応じて、検査行列を導出する検査行列導出部と、
前記検査行列を用いて、前記データパケットから冗長パケットを生成する冗長パケット生成部と、
前記データパケット及び前記冗長パケットを送信する送信部と、
を備える送信装置。 - 請求項1に記載の送信装置であって、
前記検査行列導出部は、前記結合判定部により他のフレームと結合すると判定された場合、エンコードされたフレームと前記送信部により送信されたデータパケットのフレームとを結合し、前記検査行列を導出する送信装置。 - 請求項1または2に記載の送信装置であって、
前記結合判定部は、当該送信装置と前記パケットを受信する受信装置との間における往復伝送時間に基づいて、エンコードされたフレームと他のフレームとを結合するか否かを判定する送信装置。 - ネットワークを介してパケットを受信する受信装置であって、
パケットを受信する受信部と、
前記受信部により受信されたパケットに含まれる、検査行列の生成のためにフレームが結合されたか否かを示す情報に基づいて、前記検査行列を導出する検査行列導出部と、
前記受信部により受信されたデータパケット及び冗長パケットと、前記検査行列と、に基づいて、誤り訂正復号する復号部と、
を備える受信装置。 - 請求項4に記載の受信装置であって、更に、
前記データパケットに対応するフレームがデコードされる復号時刻以前の所定時刻になるまで、前記パケットをバッファする受信バッファ部を備え、
前記検査行列導出部は、前記受信バッファ部に蓄積されたパケットに対応する複数のフレームを結合し、前記検査行列を導出する受信装置。 - ネットワークを介してパケットを送信する送信装置における送信方法であって、
データがエンコードされたフレームからデータパケットを生成するステップと、
前記生成される前記フレームあたりのデータパケット数に基づいて、前記フレームを他のフレームと結合するか否かを判定するステップと、
前記判定の結果に応じて、検査行列を導出するステップと、
前記検査行列を用いて、前記データパケットから冗長パケットを生成するステップと、
前記データパケット及び前記冗長パケットを送信するステップと、
を有する送信方法。 - ネットワークを介してパケットを受信する受信装置における受信方法であって、
パケットを受信するステップと、
前記受信されたパケットに含まれる、検査行列の生成のためにフレームが結合されたか否かを示す情報に基づいて、前記検査行列を導出するステップと、
前記受信されたデータパケット及び冗長パケットと、前記検査行列と、に基づいて、誤り訂正復号するステップと、
を有する受信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012249442A JP2014099708A (ja) | 2012-11-13 | 2012-11-13 | 送信装置、受信装置、送信方法、及び受信方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012249442A JP2014099708A (ja) | 2012-11-13 | 2012-11-13 | 送信装置、受信装置、送信方法、及び受信方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2014099708A true JP2014099708A (ja) | 2014-05-29 |
Family
ID=50941393
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2012249442A Pending JP2014099708A (ja) | 2012-11-13 | 2012-11-13 | 送信装置、受信装置、送信方法、及び受信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2014099708A (ja) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2016203870A1 (ja) * | 2015-06-17 | 2016-12-22 | ソニー株式会社 | 送信装置、送信方法、及び通信システム |
| JP2021505081A (ja) * | 2017-11-30 | 2021-02-15 | 華為技術有限公司Huawei Technologies Co.,Ltd. | ビデオ伝送方法、ビデオ伝送装置、およびビデオ伝送システム、ならびにコンピュータ可読記憶媒体 |
| JP2022122466A (ja) * | 2021-02-10 | 2022-08-23 | ソフトバンク株式会社 | 通信システム、通信装置、及びプログラム |
| CN115085859A (zh) * | 2021-03-15 | 2022-09-20 | 海能达通信股份有限公司 | 一种抗丢包方法、装置及计算机可读存储介质 |
| WO2024255297A1 (zh) * | 2023-06-12 | 2024-12-19 | 华为技术有限公司 | 一种编码方法、解码方法和计算设备 |
-
2012
- 2012-11-13 JP JP2012249442A patent/JP2014099708A/ja active Pending
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2016203870A1 (ja) * | 2015-06-17 | 2016-12-22 | ソニー株式会社 | 送信装置、送信方法、及び通信システム |
| US10687067B2 (en) | 2015-06-17 | 2020-06-16 | Sony Corporation | Transmitter, transmission method, and communication system |
| JP2021505081A (ja) * | 2017-11-30 | 2021-02-15 | 華為技術有限公司Huawei Technologies Co.,Ltd. | ビデオ伝送方法、ビデオ伝送装置、およびビデオ伝送システム、ならびにコンピュータ可読記憶媒体 |
| JP7030984B2 (ja) | 2017-11-30 | 2022-03-07 | 華為技術有限公司 | ビデオ伝送方法、ビデオ伝送装置、およびビデオ伝送システム、ならびにコンピュータ可読記憶媒体 |
| JP2022122466A (ja) * | 2021-02-10 | 2022-08-23 | ソフトバンク株式会社 | 通信システム、通信装置、及びプログラム |
| JP7138739B2 (ja) | 2021-02-10 | 2022-09-16 | ソフトバンク株式会社 | 通信システム、通信装置、及びプログラム |
| JP2022177077A (ja) * | 2021-02-10 | 2022-11-30 | ソフトバンク株式会社 | 通信端末、及びプログラム |
| JP7400042B2 (ja) | 2021-02-10 | 2023-12-18 | ソフトバンク株式会社 | 通信端末、及びプログラム |
| CN115085859A (zh) * | 2021-03-15 | 2022-09-20 | 海能达通信股份有限公司 | 一种抗丢包方法、装置及计算机可读存储介质 |
| CN115085859B (zh) * | 2021-03-15 | 2023-11-24 | 海能达通信股份有限公司 | 一种抗丢包方法、装置及计算机可读存储介质 |
| WO2024255297A1 (zh) * | 2023-06-12 | 2024-12-19 | 华为技术有限公司 | 一种编码方法、解码方法和计算设备 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107888342B (zh) | 一种网络实时视频传输方法及装置 | |
| US10320520B2 (en) | Communication device, system and method | |
| JP5588019B2 (ja) | 信頼性のあるデータ通信のためにネットワーク抽象化レイヤを解析する方法および装置 | |
| CN1878049B (zh) | 通过使用纠错包控制传输速率的方法及其通信设备 | |
| JP5991598B2 (ja) | データ処理装置及びデータ処理方法 | |
| EP2493105A1 (en) | Method and system for recovering lost media data packets | |
| KR20090119898A (ko) | 비디오 전송 중 패킷 손실의 영향 줄이기 | |
| JP2020502832A (ja) | データストリーミングの前方誤り訂正 | |
| KR20120117907A (ko) | 재전송 결정을 위한 장치 및 방법 | |
| US20150103885A1 (en) | Real time ip video transmission with high resilience to network errors | |
| JP2014099708A (ja) | 送信装置、受信装置、送信方法、及び受信方法 | |
| WO2012096396A1 (en) | Communication apparatus, communication method and storage medium for flexible error correction | |
| CN104221317B (zh) | 发送装置、接收装置、发送方法及接收方法 | |
| US9697328B2 (en) | Transmission apparatus, transmission method, reception apparatus, reception method, and computer program | |
| JP6278275B2 (ja) | 送信装置、受信装置、送信方法および受信方法 | |
| KR101953580B1 (ko) | 영상회의 시스템에서 데이터 송수신 장치 및 방법 | |
| JP4702443B2 (ja) | 通信システム、通信方法、通信装置、およびプログラム | |
| US8948252B2 (en) | Moving picture transmission apparatus, moving picture transmission system, moving picture transmission method, and program | |
| EP1489786A1 (en) | Data transmission device, repeater device, data transmission/reception device, and data communication method | |
| Tsai et al. | MAC-level forward error correction mechanism for minimum error recovery overhead and retransmission | |
| JP2014011670A (ja) | 送信装置、受信装置、送信方法、及び受信方法 | |
| JP5523163B2 (ja) | 送信装置、送信方法、プログラム | |
| JP2011211616A (ja) | 動画像伝送装置、動画像伝送システム、動画像伝送方法およびプログラム | |
| JP2014007664A (ja) | 送信装置、通信システム、及び送信方法 | |
| US20140010242A1 (en) | Apparatus and method for transmitting/receiving data in communication system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20150116 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20150312 |