JP5409032B2 - 送信装置、及び、方法、プログラム - Google Patents

送信装置、及び、方法、プログラム Download PDF

Info

Publication number
JP5409032B2
JP5409032B2 JP2009026377A JP2009026377A JP5409032B2 JP 5409032 B2 JP5409032 B2 JP 5409032B2 JP 2009026377 A JP2009026377 A JP 2009026377A JP 2009026377 A JP2009026377 A JP 2009026377A JP 5409032 B2 JP5409032 B2 JP 5409032B2
Authority
JP
Japan
Prior art keywords
frame
data packet
packet
data
fec
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.)
Expired - Fee Related
Application number
JP2009026377A
Other languages
English (en)
Other versions
JP2010183439A (ja
Inventor
亨 強矢
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to JP2009026377A priority Critical patent/JP5409032B2/ja
Priority to US12/700,617 priority patent/US8503444B2/en
Publication of JP2010183439A publication Critical patent/JP2010183439A/ja
Application granted granted Critical
Publication of JP5409032B2 publication Critical patent/JP5409032B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056Systems characterized by the type of code used
    • H04L1/007Unequal error protection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056Systems characterized by the type of code used
    • H04L1/0057Block codes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0078Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0083Formatting with frames or packets; Protocol or part of protocol for error control

Description

本発明は、有線あるいは無線のネットワークにおけるデータの送信方法に関する。
近年、通信システムの発達により、比較的大きなデータ通信帯域が必要となる動画像データの通信が一般に行なわれている。
このような動画像データの通信を行なうためには、RTP(A Transport Protocol for Real−Time Applications)と呼ばれる形式が一般的に用いられる。RTPは、音声や動画像などをリアルタイムでデータ転送するためのプロトコルである。
RTPを用いて送信される音声データや動画像データが通信に失敗した場合に、通信に失敗したデータを受信装置が復元するために、例えば、FEC(Forward Error Correction:前方誤り訂正)と呼ばれる技術が用いられる。
FECは、誤り訂正符号の技術を使って、データ転送中に発生するビットエラーやパケットの損失を回復する技術である。送信側は、送信データから誤り訂正符号化によって、冗長データを生成し、送信データに付加して送信する。
受信側は、受信データの誤り及び/又はパケットの損失を検出した場合、正常に受信したデータと冗長データを用いて誤り訂正符号を復号することで、エラーとなったパケットを復元する。
特許文献1には、通信経路上で欠落したデータパケットを、データパケットの受信側が冗長パケットを用いて復元することについて記載されている。
特開2004−159042号公報
しかしながら、損失するパケットによっては、冗長データで復元できない場合があった。
例えば、1つの動画像フレームから複数のデータパケットを生成し、さらに、送信順序が連続する4個のデータパケットごとに1個の冗長パケット(FECパケット)を生成する場合について説明する。このようなデータパケットとFECパケットを送信している状況において、例えば、4個のデータパケットのうち2個以上のパケットが欠落すると、欠落したデータパケットを復元することができなかった。
このように、短時間に複数のパケットが連続して欠落すると、欠落したデータパケットを冗長データを用いて復元できない場合があった。
本発明は上記の問題点に鑑みてなされたものであり、その目的は、冗長データで復元できない欠落データパケットの数を少なくすることである。
上記の問題点を解決するために、本発明の送信装置は、例えば以下の構成を有する。すなわち、画像データのフレームを複数に分割したデータパケットを受信装置へ送信する送信装置であって、他のフレームを参照して符号化されるフレームのデータパケットであるか否かを示す符号化タイプを各データパケットについて記憶する記憶手段と、第1のフレームのデータパケットが通信に失敗した場合に当該データパケットを前記受信装置が復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第1のフレームと同じ符号化タイプであるのフレームのデータパケットに基づいて生成する生成手段と、前記データパケットと前記復元用パケット前記受信装置に送信する送信手段とを有し、前記生成手段は、前記第1のフレームのデータパケットを前記受信装置に送信するよりも前に連続して通信に失敗したデータパケットの数が第1の数である場合、前記第1のフレームのデータパケットを復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第1のフレームよりも後に再生される第2のフレームのデータパケットとに基づいて生成し、第1のフレームのデータパケットを前記受信装置に送信するよりも前に連続して通信に失敗したデータパケットの数が前記第1の数より多い第2の数の場合、前記第1のフレームのデータパケットを復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第2のフレームよりも後に再生される第3のフレームのデータパケットとに基づいて生成する。
また、本発明の送信装置は、動画像データのフレームを複数に分割したデータパケットを受信装置へ送信する送信装置であって、他のフレームを参照して符号化されるフレームのデータパケットであるか否かを示す符号化タイプを各データパケットについて記憶する記憶手段と、第1のフレームのデータパケットが通信に失敗した場合に当該データパケットを前記受信装置が復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第1のフレームと同じ符号化タイプである他のフレームのデータパケットとに基づいて生成する生成手段と、前記データパケットと前記復元用パケットとを前記受信装置に送信する送信手段とを有し、前記生成手段は、前記第1のフレームのデータパケットの送信時刻と再生時刻の時間差が第1の時間差であった場合、前記第1のフレームのデータパケットを復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第1のフレームよりも後に再生される第2のフレームのデータパケットとに基づいて生成し、前記第1のフレームのデータパケットの送信時刻と再生時刻の時間差が前記第1の時間差よりも長い第2の時間差であった場合、前記第1のフレームのデータパケットを復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第2のフレームよりも後に再生される第3のフレームのデータパケットとに基づいて生成することを特徴とする送信装置。
本発明によれば、冗長データで復元できない欠落データパケットの数を少なくすることができる。
送信装置100の基本構成を示すブロック図である。 GOP構成の例である。 組み合わせ決定部107の処理を説明するための図である。 FECパケットのヘッダ部分のフォーマット例である。 FECパケットのヘッダの拡張例を示した図である。 拡張したFECパケットのヘッダに記録されるデータの例を示した図である。 FECパケットの生成と送信順序の例を示した図である。 同じGOPのデータパケットからFECデータを生成する例を説明するための図である。 異なるGOPのデータパケットからFECデータを生成する例を説明するための図である。 送信装置100が生成するFECパケットの例を説明するための図である。 FECパケットの生成パターンを説明するための図である。 FECパケットの生成パターンと送信順序を説明するための図である。 送信装置100と受信装置間でのデータのやり取りを示す図である。 FECフレームの生成を間引く具体例を説明するための図である。 送信装置100の動作を示すフローチャートである。
<実施形態1>
図1は、本発明の実施に好適な送信装置100の基本構成を示すブロック図である。
図1に示すように、送信装置100は、動画像符号化部101、パケット生成部102、パケット記憶部103、パケット送受信部104、フレームタイプ記憶部105、誤り訂正符号化部106、組み合わせ決定部107を備えている。尚、本形態では、映像入力装置108と送信装置100が別の装置である場合について説明しているが、これらを1つの装置として構成した場合にも、本発明は適用可能である。また、送信装置100は、伝送路109を介して不図示の受信装置に接続されている。ここで、伝送路109は、各種ネットワークに代表される伝送路であり、本実施形態においては、パケット化された動画像データなどを伝送するためのネットワークである。
動画像符号化部101は、外部の映像入力装置108より入力された動画像データを圧縮符号化する。圧縮符号化処理の代表的な方式としては、MPEG−2(ISO/IEC 13818)やMPEG−4(ISO/IEC 14496)があげられる。これらの符号化方式に共通するフレームの圧縮方式(フレームタイプ)のうち、主要な3種類の圧縮方式について説明する。
1つ目は、1つのフレーム内の情報のみでマクロブロック処理などを行ない圧縮符号化処理する方式である。この方式で圧縮されたフレームはIフレーム(Intra−coded Frame)と呼ばれる。すなわち、Iフレームは他のフレームのデータを参照せずに符号化されるフレームである。
2つ目は、時間軸上前方のフレームを参照して、動き補償予測、マクロブロック処理などをおこなう方式である。つまり、この方式は、再生時刻が前のフレームを参照して符号化する圧縮方式であり、この方式で圧縮されたフレームをPフレーム(Predicted Frame)と呼ぶ。
3つ目は、時間軸上前方、及び、時間軸上後方のフレームを参照して、動き補償予測、マクロブロック処理などを行う方式である。つまり、この方式は、再生時刻が前のフレーム、及び、後ろのフレームを参照して符号化する圧縮方式であり、この方式で圧縮されたフレームをBフレーム(Bi−directional Predicted Frame)と呼ぶ。すなわち、Pフレーム、及び、Bフレームは、他のフレームのデータを参照して符号化可能なフレームである。
また、MPEG−2において、符号化済みの複数のフレームの集合は、GOP(Group of Picture)と呼ばれる。また、MPEG−4において、符号化済みの複数のフレームの集合は、GOV(Group of Video Object Plane)と呼ばれる。本形態では、符号化済みのフレームの集合をGOPと呼ぶ。
なお、フレーム(Frame)はピクチャ(Picture)とも呼ばれるが、ここではフレーム(Frame)と呼ぶことにする。
本実施形態の動画像符号化部101は、図2に示すようなGOP構成で符号化を行う。図2において、I,P,Bの記号は、各々Iフレーム、Pフレーム、Bフレームを示すものとする。このように、1つのGOPには、フレームタイプの異なる複数のフレームが含まれる。本形態のGOPには、1個のIフレーム、4個のPフレーム、10個のBフレームが含まれる。また、図2に示したGOPの最後のBフレームの後ろに、次のGOPのIフレームが続く。本形態では、動画像データを構成する各GOPのフレームタイプの構成は同じである。
動画像符号化部101は、映像入力装置108から入力された動画像データを上記のような圧縮方式によって符号化し、符号化データをパケット生成部102に出力する。
パケット生成部102は、動画像符号化部101によって符号化された動画像データをパケット化する。つまり、パケット生成部102は、符号化された動画像データを通信に適したサイズに分割し、分割された動画像データに対して通信に必要なヘッダ情報を付与してデータパケットを生成する。
このとき、パケット生成部102は、パケット化した動画像データ(以下、データパケットと呼ぶ)のフレームタイプを、各パケットの識別情報(例えばシーケンスナンバー)と共にフレームタイプ記憶部105に記憶させる。また、パケット生成部102は、データパケットをパケット記憶部103に記憶させる。
フレームタイプ記憶部105は、パケット生成部102から出力された各パケットの識別情報と共に、フレームタイプを記憶する。また、フレームタイプ記憶部105は、組み合わせ決定部107に対し、各パケットの識別情報とフレームタイプを出力する。
組み合わせ決定部107は、フレームタイプ記憶部105から出力された各パケットの識別情報、及びフレームタイプと、伝送路109から取得した受信状況の情報に基づいて、誤り訂正符号化を行うデータパケットの組み合わせを決定する。すなわち、組み合わせ決定部107は、取得した受信状況の情報に基づいて、連続していないフレームのデータを組み合わせてFECパケットを生成するか否かを決定する。組み合わせ決定部107の具体的な処理については後述する。
誤り訂正符号化部106は、組み合わせ決定部107によって決定されたデータパケットの組み合わせに基づいて、誤り訂正用のパケット(以下、FECパケットと呼ぶ)を生成する。FECパケットは、通信に失敗したデータパケットを、受信装置が復元するために用いる復元用パケットである。本形態においてデータパケットを受信する受信装置は、通信に失敗したデータパケットを、正常に通信されたFECパケット、及び、正常に通信されたデータパケットを用いて復元できる。
尚、誤り訂正符号化の方法として代表的なものは、パリティ(XOR)符号やBCH符号、リードソロモン符号などがあげられる。本実施形態では、以下、パリティ符号によりFECパケットを生成するものとして説明するが、誤り訂正符号化の方法はパリティ符号に限定するものではなく、上述した様な方法を用いることが可能である。
本形態の誤り訂正符号化部106は、異なるGOPに属するフレームのデータパケットの組み合わせに基づいてFECパケットを生成することができる。また、誤り訂正符号化部106は、FECパケットを生成するために用いた複数のデータパケットの識別情報が、生成されるFECパケットのヘッダに含まれるように、FECパケットを生成する。
尚、識別情報については後述するが、本実施形態においては、識別情報として、データパケットのシーケンスナンバー、及び、他のデータパケットのシーケンスナンバーとの差分を用いる。このようにすることで、受信装置は、通信に失敗したデータパケットを復元するために必要なFECパケットとデータパケットを、FECパケットのヘッダを参照することで判定することができる。
誤り訂正符号化部106は、生成したFECパケットを、パケット記憶部103に記憶させる。ただし、誤り訂正符号化部106は、生成したFECパケットをパケット記憶部103に記憶させずに受信装置に対して送信するようにしても良い。
パケット送受信部104は、パケット記憶部103に記憶されたデータパケット、及び、FECパケットを伝送路109を介して受信装置に送信する。即ち、本形態の送信装置100は、複数のフレームのそれぞれが複数に分割された動画像データのデータパケットを受信装置へ送信する。
また、パケット送受信部104は、伝送路109から送信装置100宛てのパケットを受信する機能も備えており、例えば、受信装置側でのパケットの受信状況を示す情報を送信側へ通知するためのパケット(レシーバー・レポート)を受信する。
次に、組み合わせ決定部107における誤り訂正符号化の組み合わせ制御の概要を、図3を用いて説明する。
図3において、GOP(n)は、n番目のGOPであることを示している。また、GOP(n),GOP(n+1),GOP(n+2)は、再生順序が時間的に連続したGOPである。つまり、GOP(n)の最後のフレームの次に、GOP(n+1)の最初のフレーム(Iフレーム)が再生される。尚、図3では、各々のGOPをフレームタイプ毎にグループ分けした状態を示している。
本実施形態では、3種類のフレームタイプが存在するため、Iフレームグループ301とPフレームグループ302、それにBフレームグループ303に分けられる。
組み合わせ決定部107は、各フレームタイプのグループごとに、FECパケットを生成するためのデータパケットの組み合わせを決定する。つまり、組み合わせ決定部107は、Iフレームグループ301に属するデータパケットを組み合わせて、Iフレームのデータパケットに対応するFECパケットが生成されるように、データパケットの組み合わせを決定する。
また、組み合わせ決定部107は、Pフレームグループ302に属するデータパケットを組み合わせて、Pフレームのデータパケットに対応するFECパケットが生成されるように、データパケットの組み合わせを決定する。Bフレームグループ303についても同様である。従って、誤り訂正符号化部106は、上記の各フレームタイプのグループ内のデータパケットの組み合わせに基づいて、FECパケットを生成する。
このように、本形態の誤り訂正符号化部106は、異なるGOPのフレームのうち共通するフレームタイプのデータを組み合わせて誤り訂正符号化を行い、FECパケットを生成する。
このように、同じフレームタイプのフレームの組み合わせに基づいてFECパケットを生成することにより、フレームタイプによってFECパケットの冗長度を変えることが容易になる。例えば、Iフレームの冗長度を、PフレームやBフレームの冗長度よりも高くすることができる。
このように、本実施形態の組み合わせ決定部107は、属するGOPは異なるが、同じフレームタイプであるデータパケットを組み合わせてFECパケットが生成されるように、データパケットの組み合わせを決定する。しかし、この例に限らず、例えば、異なるフレームのデータパケットからFECパケットを作るようにすれば、冗長データ(FECパケット)で復元できない欠落データパケットを少なくする効果を得ることができる。また、例えば、Iフレームは他のGOPのIフレームと組み合わせてFECパケットを生成し、B、Pフレームは、同じGOP内のB、Pフレームと組み合わせてFECパケットを生成するようにしても良い。
次に、IETFによりRFC5109で定義されているFECパケットのヘッダ構成について説明する。
図4は、FECパケットのヘッダ部分のフォーマットである。本発明に関係のある部分を説明すると、『L』(401)は『length recovery』(403)の有効なビット幅を指定する1ビットのフラグである。この領域が0の場合は『length recovery』(403)の有効ビット数は16ビット、この領域が1の場合は『length recovery』(403)の有効ビット数は48ビットとなる。
『SN base』(402)は、16ビットの幅を持ち、このFECパケットにより復元可能な複数のデータパケットのうち、最もシーケンスナンバーが小さいデータパケット(データパケットA)のシーケンスナンバーを記録する。つまり、『SN base』(402)には、FECパケットに対応する複数のデータパケットのうち、再生順序が最も早いデータパケットのシーケンスナンバーが記録される。
『length recovery』(403)は、このFECパケットにより復元可能なデータパケットのメンバーを示すものである。つまり、『length recovery』(403)は、FECパケットに対応する複数のデータパケットを識別するための情報を示している。
『length recovery』(403)の先頭の1ビットは、『SN base』(402)に記録されたデータパケット(データパケットA)を意味する。また、その次の1ビットは、『SN base』(402)のデータパケットのシーケンスナンバーの次のシーケンスナンバーを持つデータパケットを意味している。つまり、『length recovery』(403)は最高で48パケット分の、シーケンスナンバーが連続したデータパケットのメンバーを示すことが可能である。
そして、各々のビットが立っているデータパケットは、このFECパケットを生成するために用いられたデータパケットのメンバーであることを意味する。例えば、『length recovery』(403)の先頭の1ビット、及び、その次の1ビット、及びさらにその次の1ビットが1で、それ以外がすべて0となっていた場合、このFECパケットは、次のようなデータパケットから生成されていることがわかる。即ち、このFECパケットは、『SN base』(402)に記録されたシーケンスナンバーのデータパケット、及び、その次のシーケンスナンバーのデータパケット、及び、さらにその次のシーケンスナンバーのデータパケットから生成されていることがわかる。
言い換えると、『length recovery』(403)のビットが立っているデータパケットは、そのFECパケットと他のメンバーのデータパケットによって復元可能できる。
このように、FECパケットのヘッダに、複数ビット(48ビット)の領域を設け、その領域内の各ビットと、シーケンスナンバーが連続するデータパケットとを対応付けてFECパケットの生成に用いたデータパケットを表現している。このようにして、受信装置側で、FECパケットのメンバーを判断することができる。しかしながら、このような方法では、『length recovery』(403)のビット数(例えば48ビット)以上、シーケンスナンバーが離れたデータパケットを用いて、FECパケットを生成することができない。
そこで、本実施形態では、FECパケットのヘッダを修正することにより、『length recovery』(403)のビット数以上、シーケンスナンバーが離れたデータパケットでFECパケットを生成できるようにしている。
図5に、FECパケットの拡張ヘッダ領域を示す。尚、本形態では、図4における『E』(404)に位置するフラグを有効にすることによって生じる拡張ヘッダ領域を使用する場合について説明する。
図5において、『num』(501)は、4ビットの幅を持つ変数で、『SN base』(402)で示されたデータパケット(データパケットA)を除く、このFECパケットのメンバーとなるデータパケットの数を示す。例えば、3個のデータパケットに対して1個のFECパケットを生成する場合、『num』(501)には、「0010」が記録される。
『bit』(502)は、4ビットの幅を持つ変数で、このFECパケットのメンバーである複数のデータパケットのシーケンスナンバーの差分を記録するためのビット幅を示す。例えば、FECパケットのメンバーである複数のデータパケットのシーケンスナンバーの差分の最大値が12ビットで表わせる場合、『bit』(502)には、「1100」が記録される。
『dsn』(503)は、『num』(501)と『bit』(502)の値を乗算した値のビット幅を持つ可変ビット幅の変数である。つまり、『dsn』(503)は、データパケットA以外の各メンバーのシーケンスナンバーと、データパケットAのシーケンスナンバーの差分を記録するための領域である。従って、例えば3個のデータパケットに対して1個のFECパケットを生成する場合で、データパケットAと他の各メンバーのシーケンスナンバーの差分が12ビットの場合、『dsn』(503)は、24ビットの領域となる。
そして、『dsn』(503)の先頭のビットから『bit』(502)で示されるビット幅の領域(例えば12ビット)に、データパケットAとデータパケットBのシーケンスナンバーの差分が示される。尚、データパケットAのシーケンスナンバーは、『SN base』(402)に記録されている。また、データパケットBは、FECパケットを生成するために用いられるデータパケットのうち、データパケットAの次にシーケンスナンバーが小さいデータパケットである。
同様に、その次のビットから『bit』(502)で示されるビット幅の領域で示される値は、データパケットAと、データパケットCのシーケンスナンバーの差分を示している。尚、データパケットCは、FECパケットを生成するために用いられるデータパケットのうち、データパケットBの次にシーケンスナンバーが小さいデータパケットである。
つまり、FECパケットの『dsn』(503)には、該FECパケットを生成するために用いられる複数のデータパケットのうち、最もシーケンスナンバーが小さいデータパケットAと、その次に小さいデータパケットBのシーケンスナンバーの差分が記録される。また、『dsn』(503)には、データパケットAのシーケンスナンバーと、データパケットBの次にシーケンスナンバーが小さいデータパケットCのシーケンスナンバーとの差分が記録される。
図6は、本実施形態におけるFECパケットのヘッダの拡張領域に記録されるデータの具体例を示したものである。
尚、動画像データのビットレートは約20Mbps、GOPの時間長は0.5秒、データパケットの平均サイズは1200バイト、当該FECパケットのメンバーとなるデータパケットの数は3個として計算している。
図6において、このFECパケットのメンバーであるデータパケットの数を示す『num』(501)の値は2である。つまり、『SN base』(402)に相当する先頭のデータパケット(データパケットA)と、その他に2個のデータパケットを用いてこのFECパケットが生成されていることがわかる。
また、『bit』(502)の値は12である。つまり、FECパケットのメンバーであるデータパケットBとデータパケットAの差分(データパケットBの識別情報)と、データパケットCとデータパケットAのシーケンスナンバーの差分(データパケットCの識別情報)は、それぞれ12ビットで示される。
また、図6の『dsn』(503)の先頭12ビットには、データパケットAとデータパケットBのシーケンスナンバーの差分が、‘010001001111’即ち1103であることが示されている。同様に、『dsn』(503)の後半12ビットには、データパケットAとデータパケットCのシーケンスナンバーの差分が、‘100010001001’即ち2185であることが示されている。
尚、上述のように、データパケットAは、該FECパケットを生成するために用いられた複数のデータパケットのうち、最もシーケンスナンバーが小さいデータパケットである。また、データパケットBは、データパケットAの次にシーケンスナンバーが小さいデータパケットであり、データパケットCは、データパケットBの次にシーケンスナンバーが小さいデータパケットである。尚、本形態では、3個のデータパケットから1個のFECパケットを生成しているが、これに限らない。
図7は、3個の連続するGOPの先頭に位置するIフレームの組み合わせによって、FECパケットが生成・送信される様子を模式的に示している。ここで、FECパケット704の『SN base』(402)には、図7のIフレーム701のデータパケットのうち、FECパケット704の生成に用いられる1個のデータパケットのシーケンスナンバーが記録される。つまり、本形態のFECパケットは、複数のフレームのデータパケットを用いて生成されるが、そのうち、最も再生順序が早いIフレーム701のデータパケットのシーケンスナンバーが『SN base』(402)に記録される。さらに、Iフレーム702を構成するデータパケットが、上述のデータパケットBに対応するデータパケットである。同様に、Iフレーム703を構成するデータパケットが、上述のデータパケットCに対応するデータパケットである。
ここで、Iフレーム701〜703の3つのIフレームを構成するデータパケットをメンバーとして生成されるFECパケットの集合を、便宜上『FECフレーム』と呼ぶ。本形態のパケット送受信部104は、FECフレーム704を、図7のようにIフレーム703よりも2〜3フレーム後に送信する。このようにIフレーム703とFECフレーム704の間隔をあけることにより、連続的に発生するエラーによってIフレーム703とFECフレーム704の両方ともが通信に失敗する可能性を低減できる。ただし、FECフレーム704の送信順序は、これに限らない。
次に、FECパケットを生成する具体的な方法について、図8及び図9を用いて説明する。
図8は、1つのフレーム内の複数のデータパケットからFECパケットを生成する方法を説明するための図である。
図8において、804にあるように、白の四角はデータパケット、斜線の四角はFECパケットを示している。データパケットグループ801は、1つのフレーム内の各データパケットをマトリクス状に配置した状態を示している。ただし、データパケットグループ801は、再生順序が隣接する複数のフレームに属するデータパケットが配置されたものであっても良い。
FECパケット802は、データパケットグループ801の横軸方向のパケットの組み合わせから生成された冗長データを格納したFECパケットである。また、FECパケットグループ803は、データパケットグループ801の縦軸方向のパケットの組み合わせから生成された冗長データを格納したFECパケットのグループである。
一方、本実施形態における複数フレームのデータパケットを用いたFECパケットの生成方法について、図9を参照しながら説明する。
図9において、データパケットグループ901とデータパケットグループ902、及びデータパケットグループ903は各々、異なるGOPに属したフレームを構成するデータパケットのグループである。例えば、データパケットグループ901は、図7におけるIフレーム701のデータパケットに相当する。同様に、データパケットグループ902は、図7におけるIフレーム702のデータパケットに相当し、データパケットグループ903は、図7におけるIフレーム703のデータパケットに相当する。また、FECパケットグループ904は、図7におけるFECフレーム704に相当するものである。つまり、FECパケットグループ904を構成する各々のFECパケットは、データパケットグループ901〜903のデータパケットを図9に示すように時間軸方向の組み合わせることによって生成される。つまり、FECパケットグループ904に示される各FECパケットは、異なるGOPに属するフレームのデータパケットを組み合わせて生成される。
また、本形態の誤り訂正符号化部106は、図9に示すように、データパケットグループ902のデータパケットに表示位置が対応するデータパケットグループ903のデータパケットを組み合わせてFECパケットを生成する。図9において、例えば、誤り訂正符号化部106は、データパケットグループ902、903、904のそれぞれの一番右上に位置するデータパケットに基づいて、FECパケットグループ904の一番右上に位置するFECパケットを生成する。この一番右上に位置するFECパケットは、データパケットグループ902、903、904の一番右上に位置するデータパケットが通信に失敗した場合に、それを復元するために用いる復元用パケットである。即ち、誤り訂正符号化部106は、Iフレーム702内の一番右上(第1の位置)に対応する第1のデータパケットの復元用パケットを、第1のデータパケットとIフレーム703内の一番右上に対応する第2のデータパケットに基づいて生成する。
尚、本実施形態の誤り訂正符号化部106は、図10に示すように、1つのフレーム内のデータパケットに基づくFECパケットグループ1001と共に、異なるGOPのデータパケットに基づくFECパケットグループ904を生成する。FECパケットグループ1001は、図8で説明したFECパケット802と同様の方法で生成されたFECパケットを複数フレーム分、示したものである。
つまり、FECパケットグループ1001は、フレームを構成するデータパケットグループの横軸方向のデータパケットの組み合わせから生成されたFECパケットと、縦軸方向のデータパケットの組み合わせから生成されたFECパケットを複数フレーム分、示したものである。ただし、図8で説明したように、1つのデータパケットグループは、1つのフレームのデータパケットであっても、例えば隣接する2つのフレームのデータパケット等であっても良い。
このように、FECパケットグループ1001とFECパケットグループ904を用いれば、より復元能力を上げることができる。ただし、異なるGOPのデータパケットで生成されるFECパケットのみを用いるようにすることも可能である。
また、誤り訂正符号化部106は、1つのフレーム内のデータパケットの組み合わせでFECパケットを生成する代わりに、再生順序が連続する複数のフレームのデータパケットの組み合わせでFECパケットを生成できることは、上述の通りである。
ところで、時間的に離れた複数のフレームのデータパケットの組み合わせによりFECパケットを生成する場合、復元に必要なFECパケットが届くタイミングが問題となる。
つまり、欠落したデータパケットを復元するために用いるFECパケットの受信時刻によっては、欠落データパケットの復元が、そのデータパケットの再生時刻に間に合わない可能性がある。例えば、図7に示されるIフレーム701の欠落データパケットを復元するためにFECフレーム704のデータを用いる場合、FECフレーム704の到着時刻が、Iフレーム701の再生時刻よりも遅いと、欠落データパケットの復元が間に合わなくなってしまう。
そこで、本実施形態の組み合わせ決定部107は、各フレームが、少なくとも1個のFECフレームにおいて最後のメンバーとなるようにFECフレームのメンバーを決定する。つまり、本形態の組み合わせ決定部107は、あるフレーム(フレームA)が複数のFECフレームのメンバーとなるようにFECフレームのメンバーを決定する。また、組み合わせ決定部107は、該複数のFECフレームのうち、少なくとも1個のFECフレームにおいて、フレームAが、再生順序が最後のメンバーとなるようにメンバーを決定する。このようにすることで、フレームAのデータパケットが通信に失敗した場合に、フレームAを最後のメンバーとするFECフレーム(FECフレームA)を用いてフレームAのデータパケットを復元することができる。尚、FECフレームAの他のメンバーのデータパケットは、フレームAよりも前に再生されるGOPのデータパケットであるため、すでに受信装置へ送信されている。
例えば、図7のIフレーム701は、FECフレーム704のメンバーである。また、Iフレーム701は、FECフレーム704のメンバー(Iフレーム701、702、703)のうち、最も送信順序が早いメンバーである。また、Iフレーム701は、FECフレーム704のメンバーであると同時に、Iフレーム701よりも前に送信されるIフレームとの組み合わせによって生成される別のFECフレームのメンバーにもなっている。
そして、組み合わせ決定部107は、別のFECフレームのうちの少なくとも1個のFECフレームにおいて、Iフレーム701が最後のメンバーとなるFECフレームがあるように、FECフレームを生成するメンバーを決定する。
尚、本形態において、FECフレームは、最後のメンバーのIフレームの2〜3フレーム後に送信される。従って、例えばIフレーム701内のデータパケットが連続して通信に失敗した場合、まずIフレーム701の2〜3フレーム後に送信されるFECフレームによって欠落データパケットの復元が試みられる。つまり、Iフレーム701が最後のメンバーであるFECフレームと他のメンバーのデータパケットによる欠落データパケットの復元が試みられる。ここで受信装置が復元できると判定すれば、Iフレーム701の欠落データパケットを、Iフレーム701の2〜3フレーム後のFECパケットにより復元できる。
このようにすれば、Iフレーム701の欠落データパケットをFECフレーム704を用いて復元する場合よりも、早く復元することができる。この説明の詳細は、図11を用いて後述する。
このように、本形態の組み合わせ決定部107は、すべてのフレームのデータパケットが、少なくとも1個のFECフレームにおいて最後のメンバーとなるように、FECフレームのメンバーを決定する。ただし、組み合わせ決定部107は、一部のフレームが、少なくとも1個のFECパケットにおいて最後のメンバーとなるように、FECフレームのメンバーを決定するようにしても良い。例えば、Iフレームが、少なくとも1個のFECフレームにおいて最後のメンバーとなるようにFECフレームのメンバーを決定するようにしても良い。
また、例えば、フレーム当たりのデータ量や、動きベクトルの大きさ等に基づいて重要度が高いと判定されるフレームが、少なくとも1個のFECフレームにおいて最後のメンバーとなるようにFECフレームのメンバーを決定するようにしても良い。このようにすれば、Iフレームや、重要度の高いフレームのデータパケットにおいて、通信の失敗を検知してから復元するまでの時間を短くすることができる。また、このようにすれば、すべてのフレームが少なくとも1個のFECフレームにおいて最後のメンバーとなるようにFECフレームを生成する場合よりも、FECパケットの数を少なくすることが可能となる。
図11は、各GOPのIフレームが、少なくとも1個のFECフレームにおいて最後のメンバーとなるようにFECフレームを生成する場合に決定される組み合わせの例を示した図である。
尚、図11に示されるGOPは、再生時刻が時間的に連続している。例えば、GOP(n−2)の次に、GOP(n−1)が再生され、その次にGOP(n)が再生される。
このとき、組み合わせ決定部107は、各FECフレームがそれぞれ異なるGOPに属するフレームの組み合わせに基づいて生成されるように、データパケットの組み合わせを決定する。例えば、FECフレームF(n)は、GOP(n−2)の先頭に位置するIフレームI(n−2)と、GOP(n−1)の先頭に位置するIフレームI(n−1)と、GOP(n)の先頭に位置するIフレームI(n)をメンバーとして生成される。
また、FECフレームF(n+1)は、GOP(n−1)の先頭に位置するIフレームI(n−1)と、GOP(n)の先頭に位置するIフレームI(n)と、GOP(n+1)の先頭に位置するIフレームI(n+1)をメンバーとして生成される。また、FECフレームF(n+2)は、GOP(n)の先頭に位置するIフレームI(n)と、GOP(n+1)の先頭に位置するIフレームI(n+1)と、GOP(n+2)の先頭に位置するIフレームI(n+2)をメンバーとして生成される。
また、IフレームI(n)は、FECフレーム(n)において最後のメンバーである。また、IフレームI(n+1)は、FECフレーム(n+1)において最後のメンバーであり、IフレームI(n+2)は、FECフレーム(n+2)において最後のメンバーである。他のIフレームについても同様である。
尚、図11には、Iフレームに対応するFECフレームしか示されていないが、誤り訂正符号化部106は、Pフレームや、Bフレームも、Iフレームと同様に、FECフレームを生成できる。
一方、Iフレーム側に視点を移すと、例えば、GOP(n)のIフレームI(n)は、GOP(n−2)のIフレームI(n−2)とGOP(n−1)のIフレームI(n−1)と共に、FECフレームF(n)のメンバーである。同様に、IフレームI(n)は、FECフレームF(n+1)とFECフレームF(n+2)のメンバーでもある。つまり、IフレームI(n)は、FECフレームF(n)とFECフレームF(n+1)と、FECフレームF(n+2)を生成するために用いられる。
即ち、誤り訂正符号化部106は、通信に失敗した第1のフレーム(IフレームI(n))のデータパケットを復元するための復元用パケット(FECフレームF(n+1))を、以下のフレームのデータパケットに基づいて生成する。即ち、誤り訂正符号化部106は、FECフレームF(n+1)を第1のフレームのデータパケットと第2のフレーム(IフレームI(n+1))のデータパケットとIフレームI(n−1)のデータパケットに基づいて生成する。
また、誤り訂正符号化部106は、通信に失敗した第2のフレームのデータパケットを復元するための復元用パケット(FECフレームF(n+2))を以下のフレームのデータパケットに基づいて生成する。即ち、誤り訂正符号化部106は、FECフレームF(n+2)を、第2のフレームのデータパケットと第3のフレーム(IフレームI(n+2))のデータパケットとIフレームI(n)のデータパケットに基づいて生成する。尚、第1のフレーム、第2のフレーム、第3のフレームは動画像符号化部101より入力される。
また、第3のフレームは第2のフレームよりも後に再生されるフレームであり、第2のフレームは第1のフレームよりも後に再生されるフレームである。
尚、本実施形態では、図11で生成されたFECフレームF(n)は、生成に用いられる複数のフレーム(IフレームI(n−2)、I(n−1)、I(n))のうち、送信順序が最後であるIフレームI(n)の2〜3フレーム後に送信される。同様に、FECフレームF(n+1)は、IフレームI(n+1)の2〜3フレーム後に送信される。また、FECフレーム(n+2)は、Iフレーム(n+2)の2〜3フレーム後に送信される。
また、図7を用いて説明したように、例えば、IフレームI(n)のデータパケットが欠落した場合、受信装置は、IフレームI(n)が最後のメンバーであるFECフレームF(n)を用いて、欠落データパケットの復元を試みることができる。また、受信装置は、FECフレームF(n)を用いてIフレーム(n)の欠落データパケットを復元できない場合、FECフレームF(n+1)を用いて欠落データパケットの復元を試みることができる。尚、FECフレームF(n+1)は、Iフレーム(n+1)の2〜3フレーム後に送信されるFECフレームである。また、受信装置は、FECフレームF(n+1)に基づいてIフレームI(n)の欠落データパケットを復元することもできない場合、FECフレームF(n+2)を用いて欠落データパケットの復元を試みることができる。尚、FECフレームF(n+2)は、Iフレーム(n+2)の2〜3フレーム後に送信されるFECフレームである。
以上のように、本形態の組み合わせ決定部107は、各フレームのデータが、複数のFECフレームの生成に用いられるように、FECフレームを生成するための組み合わせを決定する。また、組み合わせ決定部107は、すべてのフレームが、少なくとも1個のFECフレームにおいて最後のメンバーとなるように、FECフレームを生成するための組み合わせを決定する。
次に、本実施形態における誤り訂正復号によるデータ復号の例を、図12を用いて説明する。
図12は、図11の各フレーム、及びFECフレームの送信順序を示している。つまり、本形態において、各FECフレームは、最後のメンバーであるフレームの3フレーム後に送信される。ただし、この形態に限らない。
図12において、IフレームI(n)を構成するデータパケットが損失した場合、誤り訂正によって復元するルートは、Correction pass−1、Correction pass−2、とCorrection pass−3の3つある。つまり、Correction pass−1は、IフレームI(n)のデータパケットを復元するために、IフレームI(n)を最後のメンバーとするFECフレーム(FECフレームF(n))のFECパケット用いるケースである。Correction pass−1のルートで復元すれば、通信の失敗を検知してから復元する前の時間が最も短くなる。
一方、受信装置は、Correction pass−1で復元できず、遅延時間を許容できる場合には、Correction pass−2、及びCorrection pass−3のルートでの復元を試みることが可能である。Correction pass−1でデータパケットを復元できない場合として、例えば、IフレームI(n)のほかのメンバー(IフレームI(n−2)、IフレームI(n−1))のデータパケットが通信に失敗した場合がある。また、FECパケットが通信に失敗した場合もありうる。
ところで、上記の説明では、連続する3個のGOPに含まれるフレームから1個のFECフレームを生成するケースについて説明した。しかし、本形態の組み合わせ決定部107は、例えば、受信装置のバッファ容量や、遅延許容時間、バーストエラーに関する情報に基づいて、FECパケットを生成するためのデータパケットの組み合わせを決定する。
例えば、組み合わせ決定部107は、図12において、通信に失敗したIフレームI(n)のデータパケットをCorrection pass−3で復元しても、その復元が再生時刻に間に合わない場合は、FECパケットのメンバーの数を3個よりも少なくする。
また、例えば、組み合わせ決定部107は、遅延許容時間が十分に長い場合は、より離れたGOPのデータパケットの組み合わせによりFECパケットを生成するようにすることができる。
即ち、組み合わせ決定部107は、データパケットの送信時刻と再生時刻の時間差に基づいて、FECパケットを生成するために用いるデータパケットの組み合わせを決定する。
従って、誤り訂正符号化部106は、第1のフレーム(GOP(n)のIフレーム)のデータパケットの送信時刻と再生時刻の時間差が第1の時間差(例えば700msec)であった場合、以下のように復元用パケットを生成する。即ち、誤り訂正符号化部106は、第1のフレームのデータパケットを復元するための復元用パケットを、第1のフレーム(GOP(n)のIフレーム)のデータパケットと第2のフレーム(GOP(n+1)のIフレーム)のデータパケットに基づいて生成する。
一方、誤り訂正符号化部106は、第1のフレームのデータパケットの送信時刻と再生時刻の時間差が第1の時間差よりも長い第2の時間差(例えば2000msec)であった場合、以下のように復元用パケットを生成する。即ち、誤り訂正符号化部106は、第1のフレームのデータパケットを復元するための復元用パケットを、第1のフレームのデータパケットと第3のフレーム(GOP(n+2)のIフレーム)のデータパケットに基づいて生成する。
尚、第1のフレーム、第2のフレーム、第3のフレームは、動画像符号化部101によって入力される。また、第3のフレームは第2のフレームよりも後に再生されるフレームであり、第2にフレームは第1のフレームよりも後に再生されるフレームである。
また、組み合わせ決定部107は、受信装置がデータパケットを保持するためのバッファ容量が小さい場合FECフレームのメンバーとなるフレームの数を少なくする。つまり、受信装置がGOP2個分のデータパケットしか保持できない場合、受信装置は、図12のように異なる3個のGOPのデータパケットから生成されたFECパケットを用いてデータパケットを復元することができない。このような場合、組み合わせ決定部107は、受信装置のバッファ容量に合わせてFECフレームのメンバーとなるフレームの数を少なくする。このように、組み合わせ決定部107は、受信装置のバッファ容量に応じて、FECフレームを生成するために用いるフレームの数を決定する。
このように、受信装置のバッファ容量や遅延許容時間に応じてFECフレームを生成するために用いるフレームの数を少なくすれば、欠落データパケットの復元に使えないFECパケットの生成と送信をしないようにすることができる。これにより、FECパケットの生成負荷、及び、ネットワークの負荷を低減できる。
また、組み合わせ決定部107は、バーストエラーの有無に応じて、FECパケットを生成するために用いるデータパケットの組み合わせを決定する。例えば、組み合わせ決定部107は、連続してエラー(通信に失敗)したパケットの数が所定数(例えば3個)以上である場合、バーストエラーが発生していると判断する。そして、組み合わせ決定部107は、例えば、受信側のバッファ容量や遅延許容時間が十分あり、バーストエラーが発生していると判断された場合、異なるGOPのデータパケットを組み合わせてFECパケットを生成させる。
一方、組み合わせ決定部107は、バーストエラーが発生していないと判定された場合、例えば、1つのフレーム内のデータパケットで生成されたFECパケットで欠落データパケットを復元するように、データパケットの組み合わせを決定する。
また、バーストエラーの発生状況に応じて、異なるGOPのデータパケットでFECパケットを生成するか否かを決定するようにしても良い。
例えば、組み合わせ決定部107は、バーストエラーの発生頻度に応じて、データパケットの組み合わせを決定することができる。つまり、組み合わせ決定部107は、連続してエラー(通信に失敗)したパケットが所定数(例えば3個)以上である場合、バーストエラーが発生したと判定する。そして、所定の時間内に、バーストエラーが所定回数以上発生している場合、異なるGOPのデータパケットでFECパケットが生成されるように、データパケットの組み合わせを決定する。
一方、所定の時間内に、バーストエラーの発生回数が所定回数以下である場合、組み合わせ決定部107は、例えば、同じGOP(例えば、同じフレーム)のデータパケットからFECパケットが生成されるように、データパケットの組み合わせを決定する。
また、組み合わせ決定部107は、例えば、異なるGOPのデータパケットでFECパケットを生成すると決定した場合において、連続してエラーしたパケットの数が特に多いときは、FECパケットを生成するために用いるデータパケットの間隔を広げる。これは、連続してエラーしたパケットの数が特に多い場合、ネットワーク(伝送路109)が重度の輻輳状態である可能性が高いと考えられ、再び大きなバーストエラーが発生する可能性が高いと考えられる。
そこで、組み合わせ決定部107は、連続してエラーしたパケットの数に基づいて、ネットワークが重度の輻輳状態であるか判断する。そして、組み合わせ決定部107は、重度の輻輳状態であると判断される場合は、バーストエラーは発生しているものの重度の輻輳状態ではないと判断される場合よりも、FECパケットを生成するために用いるデータパケットの間隔を広げる。
具体的には、本形態の組み合わせ決定部107は、連続してエラーしたパケットの数が所定数(例えば20個)よりも少ない場合は、バーストエラーは発生しているものの、ネットワークが重度の輻輳状態ではないと判断する。この場合、組み合わせ決定部107は、例えば、再生順序が連続する2つのGOP(GOP(n)とGOP(n+1))のIフレームを組み合わせてFECフレームを生成させる。一方、組み合わせ決定部107は、連続してエラーしたパケットの数が所定数(例えば20個)よりも多い場合、重度の輻輳状態であると判定する。
組み合わせ決定部107は、例えば、受信側のバッファ容量や許容時間が十分に大きい状況で、ネットワークが重度の輻輳状態であると判断した場合、重度の輻輳状態でない場合よりも、FECパケットを生成するためのデータパケットの間隔を広げる。つまり、組み合わせ決定部107は、例えば、再生順序が連続していない2つのGOP(GOP(n)とGOP(n+2))のIフレームを組み合わせてFECフレームを生成させる。
即ち、動画像符号化部101は、第1のフレーム(GOP(n)のIフレーム)のデータと、第2のフレーム(GOP(n+1)のIフレーム)のデータと、第3のフレーム(GOP(n+2)のIフレーム)のデータを入力する。ここで、第3のフレームは、第2のフレームよりも後に再生されるフレームであり、第2のフレームは第1のフレームよりも後に再生されるフレームである。
そして、組み合わせ決定部107は、第1のフレームよりも前のフレームのデータパケットについて、連続して通信に失敗したパケット数を判断し、その判断結果に基づいてFECパケットを生成するためのデータパケットの組み合わせを決定する。従って、誤り訂正符号化部106は、第1のパケット数(例えば19個)のパケットが連続して通信に失敗した場合、以下のようにFECパケットを生成する。即ち、誤り訂正符号化部106は、第1のフレームのデータパケットを復元するための復元用パケットを、第1のフレーム(GOP(n)のIフレーム)のデータパケットと第2のフレーム(GOP(n+1)のIフレーム)のデータパケットに基づいて生成する。
一方、誤り訂正符号化部106は、第1のデータパケット数よりも多い第2のパケット数(例えば20個)のパケットが連続して通信に失敗した場合、以下のように、FECパケットを生成する。即ち、誤り訂正符号化部106は、第1のフレームのデータパケットを復元するための復元用パケットを、第1のフレーム(GOP(n)のIフレーム)のデータパケットと第3のフレーム(GOP(n+2)のIフレーム)のデータパケットに基づいて生成する。
また、組み合わせ決定部107は、例えば、異なるGOPのデータパケットでFECパケットを生成すると決定した場合において、バーストエラーの発生頻度が特に高い場合は、FECパケットを生成するために用いるデータパケットの間隔を広げる。つまり、バーストエラーの発生頻度が特に高い場合、ネットワークが重度の輻輳状態である可能性が高いと考えられる。そこで、組み合わせ決定部107は、バーストエラーの発生頻度に基づいて、ネットワークが重度の輻輳状態であるか否か判断する。
そして、重度の輻輳状態であると判断される場合は、バーストエラーは発生しているものの、重度の輻輳状態ではないと判断される場合よりも、FECパケットを生成するために用いるデータパケットの間隔を広げる。
具体的には、本形態の組み合わせ決定部107は、連続してエラーしたパケットの数が所定数(例えば3個)以上の場合にバーストエラーが発生していると判断する。そして、組み合わせ決定部107は、所定時間(例えば、100個のパケット送信する時間)内に発生したバーストエラーの回数が、例えば1回である場合は、バーストエラーは発生しているものの、ネットワークが重度の輻輳状態ではないと判断する。この場合、組み合わせ決定部107は、例えば、再生順序が連続する2つのGOP(GOP(n)とGOP(n+1))のIフレームを組み合わせてFECフレームを生成させる。
一方、組み合わせ決定部107は、所定時間内に発生したバーストエラーの回数が、所定数(例えば10回)よりも多い場合、ネットワークが重度の輻輳状態であると判定する。組み合わせ決定部107は、例えば、受信側のバッファ容量や許容時間が十分に大きい状況で、ネットワークが重度の輻輳状態であると判断した場合、重度の輻輳状態でない場合よりも、FECパケットを生成するためのデータパケットの間隔を広げる。この場合、組み合わせ決定部107は、例えば、再生順序が連続していない2つのGOP(GOP(n)とGOP(n+2))のIフレームを組み合わせてFECフレームを生成させる。
尚、本形態の組み合わせ決定部107は、受信装置から通知される、受信装置のバッファ容量や、遅延許容時間、バーストエラーに関する情報等に基づいて、FECパケットを生成するためのデータパケットの組み合わせを決定する。この情報の取得について、図13を用いて説明する。
図13は、送信装置100と受信装置間でのデータのやり取りを示す図である。
送信装置100からは、伝送路109を介して、RTPを用いてデータパケット及びFECパケットが受信装置へ送信される。一方、受信装置は、バーストエラーに関する情報と遅延許容時間とバッファサイズに関する情報を含むレシーバー・レポート1301を送信装置100へ通知する。
バーストエラーに関する情報には、例えば、バーストエラーの頻度、1回のバーストエラーにおいて連続してエラーとなったパケットの数、バーストエラーが発生している時間の情報がある。尚、所定数以上のパケットが連続してエラーとなった場合、バーストエラーが発生したと判断される。
レシーバー・レポート1301に含まれるバーストエラーの情報は、例えば、以下のようになる。すなわち、前回、レシーバー・レポート1301を送信してから発生したバーストエラーの頻度(4回)、それぞれのバーストエラーにおいて連続してエラーしたパケットの数(6個、5個、4個、9個)、及び、それぞれのバーストエラーの時間が含まれる。尚、この例では、連続してエラーとなったパケット数がすべて含まれているが、連続してエラーとなったパケット数の最大値(9個)や、平均値(6個)を含めるようにしても良い。
また、バーストエラーの頻度として、前回、レシーバー・レポート1301を送信してから発生したバーストエラーの回数を示したが、これに限らず、例えば、送信されたパケット数に対するバーストエラーしたパケット数の割合等でも良い。また、レシーバー・レポートには、上記のすべてのバーストエラーに関する情報が含まれていても、一部の情報が含まれていても良い。送信装置100は、定期的に受信するレシーバー・レポート1301に含まれるバーストエラーに関する情報に基づいて、データパケットの組み合わせを決定する。
尚、受信装置は、特に必要がない限り、遅延許容時間とバッファサイズに関する情報を、最初のレシーバー・レポート1301で送信装置100に通知する。
ところで、本実施形態のようなRTPでのパケット通信では、受信状況を把握するために、RTCP(RTP Control Protocol)というプロトコルが使用される。
RTCPでは送信装置側と受信装置側で相互に送信情報と受信情報を格納したパケットのやり取りが行なわれ、特に受信側から送信側へ通知するパケットを図13に示すようにレシーバー・レポートと呼ぶ。このレシーバー・レポートには、通常、欠落したパケットおよび受信パケットの累積数と、パケット送達時間の遅延およびジッタに関する情報などが含まれている。
本形態の受信装置は、レシーバー・レポートの拡張領域に、受信装置のバッファ容量や、遅延許容時間、バーストエラーに関する情報を格納する。そして、送信装置100の組み合わせ決定部107は、レシーバー・レポートの拡張領域の情報に基づいて、FECパケットを生成するために用いるデータパケットの組み合わせを決定する。RTCPのレシーバー・レポートは、レポートブロックを拡張することで本実施形態のように、独自の情報を格納することが可能である。
例えば、組み合わせ決定部107は、バーストエラーに関する情報のうち、バーストエラーの頻度を参照し、バーストエラーが発生したか否かを判断する。そして、組み合わせ決定部107は、バーストエラーが発生したと判断された場合は、異なるGOPのデータパケットでFECパケットを生成させ、バーストエラーが発生していないと判断された場合は、同じGOPのデータパケットでFECパケットを生成させる。
また、組み合わせ決定部107は、バーストエラーの頻度が所定値よりも高い場合は、頻度が所定値よりも低い場合より、FECパケットを生成するために用いるデータパケットの間隔を広げることが可能である。
また、例えば、組み合わせ決定部107は、バーストエラーに関する情報のうち、連続してエラーとなったパケットの数を参照し、バーストエラーが発生したか否かを判断する。そして、組み合わせ決定部107は、バーストエラーが発生したと判断された場合は、異なるGOPのデータパケットでFECパケットを生成させ、バーストエラーが発生していないと判断された場合は、同じGOPのデータパケットでFECパケットを生成させる。
また、組み合わせ決定部107は、連続してエラーとなったパケットの数が所定値よりも多い場合は、所定値より少ない場合よりも、FECパケットを生成するために用いるデータパケットの間隔を広げることが可能である。
尚、ここまでの説明では、すべてのGOPで同じようにFECフレームを生成するケースについて説明したが、FECフレームの生成を間引くことも可能である。
例えば、遅延許容時間とバッファサイズに余裕がある場合は、FECフレームの生成を間引くことで、送信するデータ量を削減することができる。このようにすれば、通信経路(伝送路109)上の通信量を少なくすることができる。
FECフレームの生成を間引く場合の具体例について、図14を用いて説明する。
図14において、ケースA1401はGOP2個おきにFECフレームを生成する例を示している。ケースA1401に示すように、組み合わせ決定部107は、1つ目と2つ目のGOPを組み合わせてFECパケットを生成し、3つ目と4つ目のGOPを組み合わせてFECパケットを生成させることが可能である。このようにすれば、1つ目と2つ目のGOPを組み合わせてFECパケットを生成し、2つ目と3つ目のGOPを組み合わせてFECパケットを生成し、3つ目と4つ目のGOPを組み合わせてFECパケットを生成するよりも、FECパケットを少なくできる。
また、ケースB1402はGOP3個おきにFECフレームを生成する場合の例を示している。このようにすれば、よりFECパケットの数を少なくできる。
特に、ネットワークが重度の輻輳状態であると判断される場合は、FECパケットの生成を減らすことにより、輻輳状態の悪化を防ぐことができる。
但し、先にも述べたように、FECフレームを生成する頻度については、遅延許容時間とバッファ容量を十分に考慮する必要がある。
次に、本実施形態の送信装置100が行う、FECパケット生成処理について、図15のフローチャートを用いて説明する。
ステップS101において、動画像符号化部101は、映像入力装置108により入力された動画像データを圧縮符号化する。そして、動画像符号化部101が、圧縮符号化された動画像データをパケット生成部102に出力すると、ステップS102に進む。
ステップS102において、パケット生成部102は、圧縮符号化された動画像データを通信に適したサイズに分割し、分割された動画像データにヘッダを付加してデータパケットを生成する。パケット生成部102が、生成されたデータパケットをパケット記憶部103に記憶させるとステップS103に進む。
ステップS103において、パケット生成部102は、ステップS102で生成したデータパケットの識別情報(例えばシーケンスナンバー)とフレームタイプをフレームタイプ記憶部105に記憶させる。フレームタイプ記憶部105がデータパケットの識別情報とフレームタイプを記憶するとステップS104に進む。
ステップS104において、組み合わせ決定部107は、各データパケットのフレームタイプの情報と、受信装置から通知されたレシーバー・レポートの情報に基づいて、FECパケットを生成するために用いるデータパケットの組み合わせを決定する。尚、組み合わせ決定部107は、レシーバー・レポートの情報に含まれる受信装置のバッファ容量、遅延許容時間、バーストエラーの情報などに基づいて、FECパケットを生成するために用いるデータパケットの組み合わせを決定する。バーストエラーの情報は、例えば、レシーバー・レポートの拡張領域に含まれる。ステップS104において、組み合わせ決定部107が決定したデータパケットの組み合わせを誤り訂正符号化部106に通知すると、ステップS105に進む。
ステップS105(生成手順)において、誤り訂正符号化部106は、組み合わせ決定部107によって決定されたデータパケットの組み合わせに基づいて、FECパケットを生成する。即ち、ステップS105において、誤り訂正符号化部106は、第1のフレームのデータパケットと第2のフレームのデータパケットに基づいて、復元用パケット(FECパケット)を生成する。尚、生成されたFECパケットは、第1のフレームのデータパケットが通信に失敗した場合に当該データパケットを受信装置が復元するために用いられる。
尚、本形態の誤り訂正符号化部106は、同じフレームタイプのフレームのデータパケットの組み合わせによりFECパケットを生成する。即ち、ステップS105において、誤り訂正符号化部106は、符号化タイプ(フレームタイプ)を判断する(判断手順)。つまり、誤り訂正符号化部106は、他のフレームのデータを参照せずに符号化されるフレーム(Iフレーム)であるか、及び、他のフレームのデータを参照して符号化可能なフレーム(B、Pフレーム)であるかを判別可能な符号化タイプを判断する。そして、誤り訂正符号化部106は、第1のフレームと符号化タイプが共通である第2のフレームのデータパケットと、第1のフレームのデータパケットとに基づいて、復元用パケット(FECパケット)を生成する。
また、誤り訂正符号化部106は、FECパケットのヘッダを、図5に示したように拡張することで、所定パケット数以上離れたデータパケットのシーケンスナンバーを含むFECパケットを生成する。即ち、ステップS105において、誤り訂正符号化部106は、第1のフレームのデータパケットの識別情報、及び、第2のフレームのデータパケットの識別情報を含む復元用パケットを生成する。尚、本実施形態では、データパケットの識別情報として、データパケットAのシーケンスナンバー、及び、データパケットAと他のメンバーとのシーケンスナンバーの差分値を用いる例を説明した。しかし、FECパケットを生成するために用いたデータパケットを識別できる情報であれば、これに限らない。
また、本形態の誤り訂正符号化部106は、異なるGOPのデータパケットを組み合わせてFECパケットを生成すると共に、同一フレーム内の送信順序が連続するデータパケットの組み合わせによりFECパケットを生成する。
即ち、ステップS105において、誤り訂正符号化部106は、通信に失敗した第1のフレームの第1のデータパケットを受信装置が復元するための第1の復元用パケットを、第1のフレームのデータパケットと第2のフレームのデータパケットに基づいて生成する。また、誤り訂正符号化部106は、通信に失敗した第1のフレームの第1のデータパケットを受信装置が復元するために用いる第2の復元用パケットを、第1のフレームの第1のデータパケットと、第1のフレームの第2のデータパケットに基づいて生成する。
このようにすれば、バーストエラーした欠落データパケットは、異なるGOPのデータパケットで生成されたFECパケットで復元でき、バーストエラーでない欠落データパケットは、フレーム内のデータパケットで生成した復元用パケットでより早く復元できる。誤り訂正符号化部106が生成したFECパケットをパケット記憶部103に記憶させると、ステップS106に進む。
ステップS106(送信手順)において、パケット送受信部104は、誤り訂正符号化部106により生成されたFECパケットを、パケット記憶部103から読み出し、受信装置へ送信する。即ち、ステップS106において、パケット送受信部104は、データパケットと復元用パケット(FECパケット)を送信する。
以上説明したように、本実施形態の組み合わせ決定部107は、FECパケットが、異なるGOPのデータパケットを組み合わせて生成されるように、FECパケットを生成するために用いるデータパケットの組み合わせを決定する。
このようにすることで、例えば、バーストエラーによって欠落したデータパケットを、異なるGOPのデータパケットを組み合わせて生成されたFECパケットを用いて復元できる。したがって、本発明によれば、冗長データ(FECパケット)に基づく復元ができない欠落データパケットの数を少なくすることができる。
<その他の実施形態>
本発明の目的は、次の形態によっても達成される。即ち、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ(またはCPUまたはMPU)が記録媒体に格納されたプログラムコードを読み出し実行する形態である。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM、CD−R、磁気テープ、不揮発性のメモリカード、ROM、DVDなどを用いることができる。
また、本発明は、コンピュータが読み出したプログラムコードを実行することにより、前述した実施例の機能が実現される形態には限られない。すなわち、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOperating System(OS)などが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれる。
さらに、本発明には、以下の形態も含まれる。すなわち、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される形態である。
101 送信装置
102 動画像符号化部
103 パケット記憶部
104 パケット送受信部
105 フレームタイプ記憶部
106 誤り訂正符号化部
107 組み合わせ決定部
108 映像入力装置
109 伝送路

Claims (9)

  1. 画像データのフレームを複数に分割したデータパケットを受信装置へ送信する送信装置であって、
    他のフレームを参照して符号化されるフレームのデータパケットであるか否かを示す符号化タイプを各データパケットについて記憶する記憶手段と、
    1のフレームのデータパケットが通信に失敗した場合に当該データパケットを前記受信装置が復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第1のフレームと同じ符号化タイプであるのフレームのデータパケットに基づいて生成する生成手段と、
    前記データパケットと前記復元用パケット前記受信装置に送信する送信手段とを有し、
    前記生成手段は、
    前記第1のフレームのデータパケットを前記受信装置に送信するよりも前に連続して通信に失敗したデータパケットの数が第1の数である場合、前記第1のフレームのデータパケットを復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第1のフレームよりも後に再生される第2のフレームのデータパケットとに基づいて生成し、
    第1のフレームのデータパケットを前記受信装置に送信するよりも前に連続して通信に失敗したデータパケットの数が前記第1の数より多い第2の数の場合、前記第1のフレームのデータパケットを復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第2のフレームよりも後に再生される第3のフレームのデータパケットとに基づいて生成することを特徴とする送信装置。
  2. 動画像データのフレームを複数に分割したデータパケットを受信装置へ送信する送信装置であって、
    他のフレームを参照して符号化されるフレームのデータパケットであるか否かを示す符号化タイプを各データパケットについて記憶する記憶手段と、
    第1のフレームのデータパケットが通信に失敗した場合に当該データパケットを前記受信装置が復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第1のフレームと同じ符号化タイプである他のフレームのデータパケットとに基づいて生成する生成手段と、
    前記データパケットと前記復元用パケットとを前記受信装置に送信する送信手段とを有し、
    前記生成手段は、
    前記第1のフレームのデータパケットの送信時刻と再生時刻の時間差が第1の時間差であった場合、前記第1のフレームのデータパケットを復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第1のフレームよりも後に再生される第2のフレームのデータパケットとに基づいて生成し、
    前記第1のフレームのデータパケットの送信時刻と再生時刻の時間差が前記第1の時間差よりも長い第2の時間差であった場合、前記第1のフレームのデータパケットを復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第2のフレームよりも後に再生される第3のフレームのデータパケットとに基づいて生成する
    ことを特徴とする送信装置。
  3. 前記生成手段は、前記通信に失敗した前記第1のフレームの第1のデータパケットを前記受信装置が復元するために用いる第1の復元用パケットを、前記第1のフレームの第1のデータパケットと前記他のフレームのデータパケットに基づいて生成し、前記通信に失敗した前記第1のフレームの第1のデータパケットを前記受信装置が復元するために用いる第2の復元用パケットを、前記第1のフレームの第1のデータパケットと前記第1のフレームの第2のデータパケットに基づいて生成する
    ことを特徴とする請求項1又は2に記載の送信装置。
  4. 画像データのフレームを複数に分割したデータパケットを受信装置へ送信する送信装置が行う送信方法であって、
    他のフレームを参照して符号化されるフレームのデータパケットであるか否かを示す符号化タイプを各データパケットについて記憶手段に記憶させる記憶工程と、
    1のフレームのデータパケットが通信に失敗した場合に当該データパケットを前記受信装置が復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第1のフレームと同じ符号化タイプであるのフレームのデータパケットに基づいて生成する生成工程と、
    前記データパケットと前記復元用パケット前記受信装置に送信する送信工程とを有し、
    前記生成工程において、
    前記第1のフレームのデータパケットを前記受信装置に送信するよりも前に連続して通信に失敗したデータパケットの数が第1の数である場合、前記第1のフレームのデータパケットを復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第1のフレームよりも後に再生される第2のフレームのデータパケットとに基づいて生成し、
    第1のフレームのデータパケットを前記受信装置に送信するよりも前に連続して通信に失敗したデータパケットの数が前記第1の数より多い第2の数の場合、前記第1のフレームのデータパケットを復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第2のフレームよりも後に再生される第3のフレームのデータパケットとに基づいて生成する
    ことを特徴とする送信方法。
  5. 動画像データのフレームを複数に分割したデータパケットを受信装置へ送信する送信装置が行う送信方法であって、
    他のフレームを参照して符号化されるフレームのデータパケットであるか否かを示す符号化タイプを各データパケットについて記憶手段に記憶させる記憶工程と、
    第1のフレームのデータパケットが通信に失敗した場合に当該データパケットを前記受信装置が復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第1のフレームと同じ符号化タイプである他のフレームのデータパケットとに基づいて生成する生成工程と、
    前記データパケットと前記復元用パケットとを前記受信装置に送信する送信工程とを有し、
    前記生成工程において、
    前記第1のフレームのデータパケットの送信時刻と再生時刻の時間差が第1の時間差であった場合、前記第1のフレームのデータパケットを復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第1のフレームよりも後に再生される第2のフレームのデータパケットとに基づいて生成し、
    前記第1のフレームのデータパケットの送信時刻と再生時刻の時間差が前記第1の時間差よりも長い第2の時間差であった場合、前記第1のフレームのデータパケットを復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第2のフレームよりも後に再生される第3のフレームのデータパケットとに基づいて生成する
    ことを特徴とする送信方法。
  6. 前記生成工程において、前記通信に失敗した前記第1のフレームの第1のデータパケットを前記受信装置が復元するために用いる第1の復元用パケットを、前記第1のフレームの第1のデータパケットと前記他のフレームのデータパケットとに基づいて生成し、前記通信に失敗した前記第1のフレームの第1のデータパケットを前記受信装置が復元するために用いる第2の復元用パケットを、前記第1のフレームの第1のデータパケットと前記第1のフレームの第2のデータパケットとに基づいて生成する
    ことを特徴とする請求項4又は5に記載の送信方法。
  7. 画像データのフレームを複数に分割したデータパケットを受信装置へ送信するコンピュータに、
    他のフレームを参照して符号化されるフレームのデータパケットであるか否かを示す符号化タイプを各データパケットについて記憶手段に記憶させる記憶手順と、
    1のフレームのデータパケットが通信に失敗した場合に当該データパケットを前記受信装置が復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第1のフレームと同じ符号化タイプである第2のフレームのデータパケットに基づいて生成する生成手順と、
    前記データパケットと前記復元用パケット前記受信装置に送信する送信手順とを実行させ、
    前記生成手順において、前記第1のフレームのデータパケットを前記受信装置に送信するよりも前に連続して通信に失敗したデータパケットの数が第1の数である場合、前記第1のフレームのデータパケットを復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第1のフレームよりも後に再生される第2のフレームのデータパケットとに基づいて生成し、
    第1のフレームのデータパケットを前記受信装置に送信するよりも前に連続して通信に失敗したデータパケットの数が前記第1の数より多い第2の数の場合、前記第1のフレームのデータパケットを復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第2のフレームよりも後に再生される第3のフレームのデータパケットとに基づいて生成する処理を前記コンピュータに実行させる
    ことを特徴とするプログラム。
  8. 動画像データのフレームを複数に分割したデータパケットを受信装置へ送信するコンピュータに、
    他のフレームを参照して符号化されるフレームのデータパケットであるか否かを示す符号化タイプを各データパケットについて記憶手段に記憶させる記憶手順と、
    第1のフレームのデータパケットが通信に失敗した場合に当該データパケットを前記受信装置が復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第1のフレームと同じ符号化タイプである他のフレームのデータパケットとに基づいて生成する生成手順と、
    前記データパケットと前記復元用パケットとを前記受信装置に送信する送信手順とを実行させ、
    前記生成手順において、
    前記第1のフレームのデータパケットの送信時刻と再生時刻の時間差が第1の時間差であった場合、前記第1のフレームのデータパケットを復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第1のフレームよりも後に再生される第2のフレームのデータパケットとに基づいて生成し、
    前記第1のフレームのデータパケットの送信時刻と再生時刻の時間差が前記第1の時間差よりも長い第2の時間差であった場合、前記第1のフレームのデータパケットを復元するために用いる復元用パケットを、前記第1のフレームのデータパケットと前記第2のフレームよりも後に再生される第3のフレームのデータパケットとに基づいて生成する処理を前記コンピュータに実行させることを特徴とするプログラム。
  9. 前記生成手順において、前記通信に失敗した前記第1のフレームの第1のデータパケットを前記受信装置が復元するために用いる第1の復元用パケットを、前記第1のフレームの第1のデータパケットと前記他のフレームのデータパケットとに基づいて生成し、前記通信に失敗した前記第1のフレームの第1のデータパケットを前記受信装置が復元するために用いる第2の復元用パケットを、前記第1のフレームの第1のデータパケットと前記第1のフレームの第2のデータパケットとに基づいて生成する処理を前記コンピュータに実行させる請求項7又は8に記載のプログラム。
JP2009026377A 2009-02-06 2009-02-06 送信装置、及び、方法、プログラム Expired - Fee Related JP5409032B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2009026377A JP5409032B2 (ja) 2009-02-06 2009-02-06 送信装置、及び、方法、プログラム
US12/700,617 US8503444B2 (en) 2009-02-06 2010-02-04 Transmission device, transmission method, and program for the same

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009026377A JP5409032B2 (ja) 2009-02-06 2009-02-06 送信装置、及び、方法、プログラム

Publications (2)

Publication Number Publication Date
JP2010183439A JP2010183439A (ja) 2010-08-19
JP5409032B2 true JP5409032B2 (ja) 2014-02-05

Family

ID=42540336

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009026377A Expired - Fee Related JP5409032B2 (ja) 2009-02-06 2009-02-06 送信装置、及び、方法、プログラム

Country Status (2)

Country Link
US (1) US8503444B2 (ja)
JP (1) JP5409032B2 (ja)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5075536B2 (ja) * 2007-09-03 2012-11-21 株式会社東芝 Fec送信処理装置、ならびにfec送信処理のための方法およびプログラム
US8633963B2 (en) * 2010-04-27 2014-01-21 Lifesize Communications, Inc. Determining buffer size based on retransmission latency
KR20120005371A (ko) * 2010-07-08 2012-01-16 한국전자통신연구원 블록 코드 심볼을 중복하여 버스트 데이터 손실을 복구하는 방법 및 장치
US8671333B2 (en) 2011-06-29 2014-03-11 Lsi Corporation Adaptive encoding and decoding for error protected packet-based frames
GB2492830B (en) * 2011-07-14 2018-06-27 Skype Correction data
US10498359B2 (en) 2011-07-14 2019-12-03 Microsoft Technology Licensing, Llc Correction data
US20130142094A1 (en) * 2011-12-02 2013-06-06 Qualcomm Incorporated Systems and methods for frame filtering and for enabling frame filtering
US9407923B2 (en) 2013-05-20 2016-08-02 Gamefly Israel Ltd. Overconing lost IP packets in streaming video in IP networks
JP6294346B2 (ja) * 2013-11-15 2018-03-14 株式会社日立製作所 通信装置及びシステム及び方法
KR101525353B1 (ko) * 2014-05-26 2015-06-04 한국산업기술대학교산학협력단 메타데이터를 활용한 옥외 광고전자 시스템을 위한 데이터 복원 장치 및 방법
JP6412160B2 (ja) * 2014-12-12 2018-10-24 株式会社日立製作所 通信装置、通信装置システム及び通信方法
US10687067B2 (en) 2015-06-17 2020-06-16 Sony Corporation Transmitter, transmission method, and communication system
US10541770B2 (en) * 2017-02-06 2020-01-21 Valens Semiconductor Ltd. Efficient recovery of lost packets using double parity forward error correction
US10291936B2 (en) 2017-08-15 2019-05-14 Electronic Arts Inc. Overcoming lost or corrupted slices in video streaming
CN112312204B (zh) * 2020-09-30 2022-05-24 新华三大数据技术有限公司 一种视频流数据分片的组包方法及装置
JP2023095138A (ja) * 2021-12-24 2023-07-06 日本電気株式会社 通信装置、通信方法、プログラム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3591712B2 (ja) * 1999-04-02 2004-11-24 松下電器産業株式会社 動画送信装置及び動画受信装置
AU2001276731A1 (en) * 2000-08-25 2002-03-04 Matsushita Electric Industrial Co., Ltd. Data transmission method and data relay method
JP4088956B2 (ja) 2002-11-06 2008-05-21 ソニー株式会社 情報処理装置
US7668712B2 (en) * 2004-03-31 2010-02-23 Microsoft Corporation Audio encoding and decoding with intra frames and adaptive forward error correction
JP4559126B2 (ja) * 2004-06-01 2010-10-06 日本電信電話株式会社 映像送信方法、映像送信装置、映像送信用プログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体
US7539187B2 (en) * 2004-07-07 2009-05-26 Qvidium Technologies, Inc. System and method for low-latency content-sensitive forward error correction
JP4532505B2 (ja) * 2004-12-09 2010-08-25 三菱電機株式会社 データ送信装置、データ受信装置、およびデータ配信システム
JP4392004B2 (ja) * 2006-07-03 2009-12-24 インターナショナル・ビジネス・マシーンズ・コーポレーション パケット回復のための符号化および復号化技術
US7870465B2 (en) * 2006-10-18 2011-01-11 Versteeg William C Reducing channel-change time

Also Published As

Publication number Publication date
JP2010183439A (ja) 2010-08-19
US8503444B2 (en) 2013-08-06
US20100202309A1 (en) 2010-08-12

Similar Documents

Publication Publication Date Title
JP5409032B2 (ja) 送信装置、及び、方法、プログラム
JP5408981B2 (ja) 通信装置、及び通信方法、プログラム
JP5100311B2 (ja) 動画像データ送信方法、通信装置、及びプログラム
US8855145B2 (en) Jitter buffer
US9246644B2 (en) Jitter buffer
US8185792B2 (en) Data-transmission device data-reception device and data-transmission-and-reception system
CN101098209A (zh) Fec编码方法、fec解码方法和fec解码设备
JP2011523806A (ja) 放送チャネル上の高速チャネルザッピングおよび高品質ストリーム保護
JP5677070B2 (ja) 受信装置及び、受信装置による処理方法
US8948213B2 (en) Jitter buffer
JP4041137B2 (ja) 映像符号化・送信装置,映像符号化・送信方法,映像符号化・送信プログラムおよびその記録媒体
JP5553663B2 (ja) 映像送信装置、映像受信装置、映像伝送システム
JP2005012753A (ja) パケット中継装置及びその方法と、パケット受信装置及びその方法と、パケット中継プログラム及びそのプログラムを記録した記録媒体と、パケット受信プログラム及びそのプログラムを記録した記録媒体
JPWO2008139882A1 (ja) 通信システムおよび通信方法、並びに、プログラム
US20130058409A1 (en) Moving picture coding apparatus and moving picture decoding apparatus
JP3927443B2 (ja) 動画像送受信システムおよび動画像送受信方法
US10116415B2 (en) Transmission device, receiving device, transmission method, and receiving method
JP2001086153A (ja) データ通信装置、データ通信システム、データ通信方法及び記憶媒体
JP2017516346A (ja) 通信システムにおけるパケット送受信方法及び装置
US8819526B2 (en) Method and apparatus for recovering burst data loss by duplicating block code symbols
JP4752898B2 (ja) コンテンツ配信システム、受信装置及び再生プログラム
JP5939884B2 (ja) 誤り訂正符号化装置
JP2006352784A (ja) 伝送方法、受信装置及びコンピュータプログラム
JP5262536B2 (ja) コンテンツ配信システム、配信装置、再生装置、配信方法、再生方法およびプログラム
JP2011193415A (ja) 動画像データ伝送装置および動画像データ伝送方法

Legal Events

Date Code Title Description
RD01 Notification of change of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7421

Effective date: 20100630

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120206

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130412

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130423

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130624

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20131008

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20131105

R151 Written notification of patent or utility model registration

Ref document number: 5409032

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

LAPS Cancellation because of no payment of annual fees